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VIEW CONFIGURER IN A PRESENTATION fonnat, and when the connection is closed in the above 

SERVICES PATTERNS ENVIRONMENT interacUon, the server serves a passive role, i.e., it accepts 

commands from the client and cannot request the client to 

CROSS REFERENCE TO RELATED perform any action. 

APPUCATIONS 5 xhe communication model under the conventional Web 

This application is related to United States Patent AppU- environment provides a very limited level of interaction 

cations entitled A SYSTEM, METHOD AND ARTICLE OF between clients and servers. In many systems, increasing the 

MANUFACTURE FOR A DEVELOPMENT ARCHTTEC- ^^^^^ interaction between components in the systems 

TURE FRAMEWORK Ser. No. 09/387,747 and A ^® systems more robust, but increasing the 

SYSTEM, METHOD AND ARTICLE OF MANUFAC- interaction increases the complexity of die interaction and 

TURE FOR MAINTENANCE AND ADMINISTRARON typically slows the rate of the interaction. Thus, the con- 

IN AN E-COMMERCE APPUCAOON FRAMEWORK ventional Web environment provides less complex, faster 

Ser. No. 09/387,318, both of which are filed concurrendy interactions because of tiie Web's level of interaction 

herewith and which are incorporated by reference in their between cUents and servers. 

^^^^^y- SUMMARY OF THE INVENTION 

FIELD OF THE INVENTION Asystem, method and article of manufacture are provided 

TTie present invention relates to configuring views and assigning a view to an activity. Notification is received 

more particularly to assigning views to an activity. 20 * ^ activity has occurred. A reference 

to a first instance of an object created by the startup event of 

BACKGROUND OF THE INVENTION activity is also received. A view to launch is determined 

in response to the receipt of the notification and the refer- 

An important use of computers is the transfer of infor- ence. The view is based on predetermined criteria. The view 

mation over a network. Cunentiy, the largest computer is associated with the activity and displayed, 

network in existence is the Internet. The Internet is a ^ t„ ^„ «f tu^ • • ♦* *u j * • j 

„^ 1*'. . * ^* r * J *u * In&n aspect of the present mvention, the predetermmed 

worldwide interconnection of computer networks that com- ^t^^*, * t ^ c 

... . V ^ . catena may mclude user preferences, an expenence level of 

municate using a common protocol. Millions of computers, , ai a/ i « » .i. 

&om low end peisonal computeis to high-end super com- ^^/^'^P^Sf'^f '"^K ^^'.^ T"^!! 

puteK are coupled to the Internet. .^t the present uiventaon, ^ 

*^ *^ 30 run without a corre^nding view. In a further aspect of 

The Internet grew out of work funded in the 1960s by the the present invention, the activity may operate on a machine 

U.S. Defense Department's Advanced Research Projects separate from a machine of an end user. 

Agency. For a long time, Internet was used by researchers in i .i* • r *i_ 

- J , t i_ * • ^ L • *n one embodiment of the present mvention, a request 

universities and national laboratones to share information. _ , ♦*u *^ j-Tt-. 

A r^u ¥ * *i_ 1 may be sent to be nolined when a new instance of an obiect 

As the existence ot the Internet became more widely known, ,v i« *u ™u j- * r*u 

^ . J ^ ^. J • / L . ' 35 IS created. In another embodiment of the present invention, 

many users outside of the academic/research community *• ci . j r • • ^ 

/ I CI w . . ^ coimguration me may be read for obtammg configuration 

(e.g., employees of large corporations) started to use Internet information & & 

to carry electronic mail. 

In 1989, a new type of information system known as the BRIEF DESCRIPTION OF THE DRAWINGS 

World-Wide-Web ("the Web**) was introduced to the Inter- an - -i, i_ i_ . . . 

net. Early development of die Web took place at CERN, the invention will be better understood when consider- 

European Particle Physics Laboratory. Tlie Web is a wide- ^ the followmg detailed descnption thereof, 

area hypermedia information retrieval system aimed to give ^"f^ d^npUon makes reference to tiie amiexed drawmgs 

wide access to a large universe of documents. At that time, ^ erein. 

the Web was known to and used by the academic/research 45 f'^* ^ ^ ^ schematic diagram of a hardware implemen- 

community only. There was no easily available tool which ^^0° °f embodiment of the present invention; 

allows a technically untrained person to access the Web. FIG. 2 is a flow diagram illustrating a high level overview 

In 1993, researchers at the National Center for Supercom- °^ ^ architecture; 

puling Applications (NCSA) released a Web browser called FIG. 3 shows the dependencies of three architecture 

"Mosaic" that implemented a graphical user interface (GUI). 50 firameworks; 

Mosaic's graphical user interface was simple to learn yet FIG. 4 illustrates a delivery vehicle matrix; 

powerful. The Mosaic browser allows a user to retrieve yIG. 5 illustrates a Delivery Vehicle Cube; 

documents fiom the World-Wide-Web using simple point- ^ ^ a j- j*.- 

„ . , , „ *u J * if * i_ o IS a now diagram depictmg considerations to be 

and-click commands. Because the user does not have to be . , . » j l -j • .1. . ^ ^ 

... 1, ... J ^, t . , , , taken mto consideration when identifying the core technolo- 

technically tramed and the browser is pleasant to use, it has 55 oies to be used in an architecture* 

the potential of opening up the Internet to the masses. ' 

T*. ^ r.t. Ti/urn t i- . FIG. 7 IS a chart that cau be utilized to determine whether 

I ne architecture of the Web follows a conventional client- ^ Netcentric techn I 

server model. The terms "client** and "server** are used to „^ ^ • i_ l 

refer to a computer's general role as a requester of data (the FIG. 8 is a chart that can be uUhzed to determine whether 

cUent) or provider of data (the server). Under tiie Web 60 ^ technology; 

environment, Web browsers reside in chents and Web docu- ^IG. 9 is a chart that can be utilized to determine whether 

ments reside in servers. Web clients and Web servers com- ^ technology; 

municate using a protocol called "HyperText Transfer Pro- FIG. 10 illustrates the services of a Netcentric Architec- 

tocol" (HTTP). A browser opens a connection to a server and lure Framework in accordance with one embodiment of the 

initiates a request for a document. The server deUvers the 65 present invention; 

requested document, typically in die form of a text document FIG. 11 is a detailed diagram of some of die components 

coded in a standard Hypertext Markup Language (HTML) of the Netcentric Architecture Framework found in FIG. 10; 
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FIG. 12 is a detailed diagram of other components of the FIG. 44 shows a high level picture of application com- 

Netceotric Architecture Framework found in FIG. 10; ponent interaction for an Order Entry system; 

FIG. 13 illustrates several components of the Presentation FIG. 45 illustrates a traditional oiganization structure 

area of the Netcentric Architecture Framework; including an activities component, a credit/collections 

FIG. 14 illustrates several components of the Inforaaation ^ component, a billing component, and a finance component; 

Services of the present invention; FIG. 46 provides an illustration of a horizontal orgaoiza- 

FIG. 15 depicts the four major categories of functionality tion model; 

that the Network services provided by the Communications HG. 47 aiustrates a workcell organization approach 

Services are grouped into; including an activities component, a credit/collections 

FIG. 16 illustrates File Sharing services; component, a billing component, and a finance component; 

FIG. 17 depicts Message Passing services; FIG. 48 illustrates the Enterprise Information Architecture 

HG. 18 depicts Message Queuing services; (EIA) model; 

FIG, 19 illustrates Publish and Subscribe services; FIG. 49 illustrates a V-model of Verification, Validation, 

FIG. 20 depicts Streaming, in which a real-time data 15 and Testing; 

stream is transferred; FIG. 50 portrays of a development architecture with a 

HG. 21 illustrates CORBA-based Object Messaging; seamless integration of tools which can be plugged in for the 

FIG. 22 illustrates COM Messaging; capture and communication of particular deliverables; 

FIG. 23 represents CTI Messaging; I^G. 51 shows a design architecture with the compro- 

FIG. 24 iOustrates various components of the Communi- ^ today's component construction environ- 

cation Fabric of the present invention; ment; 

FIG. 25 illustrates the two categories of the Physical illustrates a business process to object mapping; 

Media; FIG. 53 is a diagram which illustrates a graph of resilience 

HG. 26 illustrates several of the components of the 25 to change; 

Transaction areas of the Netcentric Architecture Frameworic; FIG. 54 illustrates a flowchart for a method for providing 

FIG. 27 illustrates various components of the Environ- ^ abstraction factory pattern in accordance with an embodi- 

mental Services of the Netcentric Architecture Framework; ™^°t ^® present invention; 

FIG. 28 illustrates the Base Services of the Netcentric ^G. 55 illustrates a flowchart for a method for rcpresent- 
Architecture Framework; ^ ing a plurality of batch jobs of a system each with a unique 

FIG. 29 shows the major compor^nts of the reporting ^ accordance with an embodiment of the present 

application fi-amework; mvention; 

FIG. 30 illustrates an example of how a custom report illustrates a_ class diagram of the batch jt* 
architecture relates to a workstation platform technology 35 hierarchy; 

architecture; FIG. 57 illustrates an object interaction graph of a pos- 

FIG. 31 describes the relationships between the major ^ible implementation of the class diagram of FIG. 56; 

components of the report process and the report writer FIG. 58 illustrates a flowchart for a method for controlling 

process; access to data of a business object via an attribute dictionary 

HG. 32 shows the module hierarchy for the custom report 40 ^ accordance with an embodiment of the present invention; 

process; FIG. 59 iUustrates a flowchart for a method for structuring 

FIG. 33 depicts the various components of the Business batch activities for simplified reconfiguration in accordance 

Logic portion of the Netcentric Architecture Framework; with an embodiment of the present invention; 

FIG. 34 iUustrates a relationship between major themes FIG. 60 illustrates the manner in which the AttributeDic- 
that impact aspects of software development and manage- 45 tionaryClient is the facade which delegates to the Attribute- 

ment; Dictionary; 

FIG. 35 iUustrates how components are viewed firom FIG. 61 depicts the use of the contaiiisKey( ) method on 

different perspectives; the HashMap to ensure that the value will exist before the 

FIG. 36 shows a relation^ip between business compo- get( ) method is used; 

nents and partitioned business components; FIG. 62 illustrates a method that dictates that any 

FIG. 37 shows how a Billing Business Component may nuUPointerExoeption that is thrown would be caught and 

create an invoice; rethrown as the more user-fiiendly exception in the attribute 

FIG. 38 iUustrates the relationship between the spectrum dictionary pattern environment; 

of Business Components and the types of Partitioned Busi- FIG. 63 iUustrates the Get the Attribute Names method in 

ness Components; the attribute dictionary pattern environment; 

FIG. 39 iUustrates the flow of workflow, dialog flow, FIG. 64 iUustrates a flowchart for a method for managing 

and/or user interface desigos to a User Interface Component; constants in a computer program in accordance with an 

FIG. 40 is a diagram of an y^plication Model which embodiment of the present invention; 

iUustrates how the different types of Partitioned Business FIG, 65 iUustrates a flowchart for a method for providing 

Components might interact with each other; a fixed format stream-based communication system in 

FIG. 41 iUustrates what makes up a Partitioned Business accordance with an embodiment of the present invention; 

Component; FIG. 66 iUustrates two systems communicating via a 

FIG. 42 iUustrates the role of patterns and frameworks; stream-based conununication and using a common generic 

FIG. 43 iUustrates this Business Component Identifying 65 format to relay the meta-data information; 

Methodology including both Planning and Delivering FIG. 67 iUustrates an example of a Fixed Format message 

stages; associated with the fixed format stream patterns; 
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FIG. 68 depicts the complete Fixed Formal Stream pattern FIG. 91 illustrates the problem associated with sending a 

associated with the fixed format stream patterns; NULL across many types of middleware; 

FIG. 69 illustrates fixed format contracts containing meta- FIG. 92 illustrates the manner in which the present 

data information for translating stmctured data onto and off invention passes a "null" structure across the middleware; 

of a stream; 5 pjQ 93 depicts conversations with a "null" data structure; 

FIG. 70 illustrates a Customer object in an object-based rg. 94 depicts conversations with a non-"null" data 

system streaming itself into a stream, the stream being sent stractuie- 

to a non-object system, this sfream being read and the data p,G 95 iu„strates a flowchart for a method for transmit- 

mserted into a relational database; j^^^ ^ ^ ^ p^g^^ accordance 

FIG. 71 illustrates a flowchart for a method for delivering with an embodiment of the present invention- 

service via a globaUy addressable interface in accordance pjc 95 ^ jhe response time for a User Interface to 

with an embodiment of the present invention; ^^^^y , „f customers in a list box; 

FIG. p depicts a cKent that is unable to find the services p,G „ ^ ( ^^ ^ j ^^^^ „j 

provided by a server via a network; ^^^^ 

FIG. 73 iUustrates the grouping of services using inter- p,g gg ^ graphical depiction of a paging commu- 

nication pattena; 

HG. 74 illustrates a customer server publicly announcing pj^ 99 iUustrates a message trace diagram showing the 

Its mteriaoes, interactions between a Qient and a Server using Paging 

HG. 75 illustrates a method including the registering and 20 Communication to satisfy the previously mentioned see- 
then locating of a globally addressable interface; nario; 

FIG. 76 illustrates the present invention using a method FIG. 100 illustrates a flowchart for a method for inter- 
wherein a globally addressable interface is used to obtain fadng a naming service and a client with the naming service 
data fi-om a server; allowing access to a plurality of different sets of services 

FIG. 77 illustrates a flowchart for a method for affording ^ fi*om a plurality of globally addressable interfaces in accor- 

access to a legacy system in accordance to an embodiment dance with an embodiment of the present invention; 

of the present invention; piG. loi illustrates repeated requests to the Trader Ser- 

FIG. 78 depicts the communication difficulties associated vice for the same interfaces; 

with Legacy Systems attempting to communicate with a piG. 102 iUustrates how a pool can be created that reuses 

client via a component integration architecture; gAI proxies; 

FIG, 79 illustrates homogenous interfaces firom compo- piG. 103 illustrates the implementation of a Refreshable 

nents which rectify the problems with Legacy Systems Proxy Pool; 

attempting to communicate with a cUent via a component ^04 illustrates the class relationships between the 

mtegrauon architecture; 3^ p^^^ ^j^^. 

FIG. 80 shows how a Legacy Component is integrated 105 illustrates a flowchart for a method for providing 

mto a component-based model; ^ self^escribing stream-based communication system in 

FIG. 81 iUustrates Legacy Wrapper Components of a Pure accordance with an embodiment of the present invention; 

Legacy Wrapper Component including a Legacy Wrapper piG. 106 iUustrates two systems communicating via 

Component, a Component Adapter; a Ugacy Integration 40 Stream-Based Communication and using a shared generic 

Architecture, a Legacy Adapter, and a Legacy System; fonnat to relay Uie metaniata information; 

FIG. 82 iUustrates a Hybrid Component type of Legacy nC. 107 iUustrates an object-based system with a &e- 

Wrapper Component; quently changing object model communicating via Stream- 

FIG. 83 shows an abstract example of the control flow in Based Communication; 

a Legacy Component; 45 iUustrates a stream-based message that contains 

FIG. 84 illustrates a flowchart for a method for deUvering both message data and descriptive meta-data; 

service via a locally addressable interface in accordance HG. 109 illustrates the manner in which a message 

with an embodiment of the present invention; language defines how to parameterize the meU-data and put 

FIG; 85 iUustrates Problems with GlobaUy Addressable it on the stream; 

Interfaces in a system including cUents and servers with a nG. 110 iUustrates a Customer object in an object-based 

phirahty of interfaces; system streaming itself into a stream, the stream being sent 

FIG. 86 iUustrates the manner in which the present to a non-object system, this stream being read and the data 

invention uses a Locally Addressable Interface to hide inserted into a relational database; 

functionality and lessen the load on the Naming or Trading FIG. Ill Ulustrates a flowchart for a meUiod for providing 

Service; a stream-based communication system in accordance with 

FIG. 87 iUustrates the maimer in which the present an embodiment of the present invention; 

invention obtains a LocaUy Addressable Interface; nC. 112 Ulustrates how systems of the present invention 

FIG. 88 iUustrates the method in which the present communicate over a communication mechanism that caimot 

invention registers and then locates a GlobaUy Addressable go inherently convey meta-data information; 

Interface; FIG. 113 is an Ulustration of an object-based system 

FIG. 89 iUustrates the manner in which the present communicating with a non-<^ject system using a commu- 

invention uses a GlobaUy Addressable Interface to obtain a nication mechanism that caimot convey meta-data informa- 

LocaUy Addressable Interface to a specific Customer Object; tion; 

FIG. 90 illustrates a flowchart for a method for conamu- 65 FIG. 114 depicts an example of Stream Based Commu- 
nicating a nuU value in accordance with an embodiment of nication with two di^arate systems communicating via 
the present invention; stream-based communication; 
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FIG. 115 is an illustration of a Customer object in an FIG. 141 illustrates a GarbageCollector requesting for 

object-based system streaming itself into a stream, the interest in context B; 

stream being sent to a non-object system, this stream being rG. 142 iUustrates a flowchart for a method for creaUng 

read and the informaUon is mserted mto a relational data- a common interface for exception handling in accordance 

^ with an embodiment of the present invention; 

FIG. U6 illustrates a flowchart for a method for effidenUy pjo. 143 fliustrates how having many different exception 

relnevmg data m accordance with an embodiment of the types wiU cause the exception handling logic to grow; 

present mvenUon; ^ ^ ^ l . 

iTTi- ii^ Mi * * *u - L 1- . FIG. 144 illustrates that groupmgs arc not always exclu- 

FIG. 117 illustrates the manner in which a chent requests ^jy^. t^- r j 

information from server objects via a network; ^° ^ .„ 

iTr/^iion . 4 *u *u J f.u • FIG. 145 illustrates a flowchart for a method for recording 

FIG. U8 mustrates the method of the present ,nvent>on in .equirements for maintaining a consis- 

jSi^Si " ' "^^^ ^ * ^""^ handling apploach in acconlance with tn embodi- 

^ menl of the present invention; 

FIG. 119 ilhistrates the transmitting of all data in a Data iviic -11, * * a u *i- j ^ 

£_ V * * J ■ 15 FIG. 146 illustrates a flowchart for a method for mim- 

Structure from a chent to a server and visa-versa; „• • *u * * u *i. . j * 1. j 

— .„ , , J . ^ . , . mizing the amount of changes that need to be made to 

FIG. 120 Olustrates the method m which a client finds and exception handUng logic when new exceptions are added in 

mstantiates a Customer Object from a customer component; accordance with an embodiment of the present invention; 

tH ^T'^'M^'^^T i^r^^^T'^^^ depicts a program (i.e., the exception handler of 
thatbuddsuponthemethodofnG 120anddepictst^^ 20 the present invention) with a few try^tch blocks; 

of control dunng Structure Based Communication; ^^oj- , 

FiamshowsFiveStylesofaient/ServerO^mputing; ,^£,1^^^^:,^,^^^''^''''''' '^'^''^ 

present invention* 25 mcommg requests amongst server components for 

.„ * , . , . o . optimizing usage of resources in accordance with an 

ma 124 lUusdrates multiple mterfaces to an apphcaUon embodiment of the present invention; 

mchidmg a handheld device, a desktop PC, and a telecom- rnr- ica n « ♦ 

munications device; illustrates server components receiving service 

requests; 

or,^^' ^ '^'^'^'^ ""^'^ relationship dia- ^ nO. 151 iUustrates a load balancer mediating the requests 

S**™' of FIG 150* 

FIG. 126 illustrates a roles and responsibilities diagram; 171^^ ie^%i * * <, . ^ 

TTir- i'>'r ;n„o..,t^ *, • 1 • 1 « *• i„*„ iUustrates a flowchart for a method for main- 

FIG. 127 iUustrates a typical implementation between a , #1 • ^ 

;„t^rf,« ^^ti,Ji., tammg a secunty profile throughout nested service mvoca- 

user mteriace and its activity; „ „„ . . , . , . . 

11 . . » \ L . ^ ®° distributed components m accordance wiUi an 
FIG. 128 iUustrates a flowchart for a method for struc- 35 embodiment of the present invention; 

turing validation rules to be appHed to a user interface for ^-^ . - * *• j- 

maximum maintainability and extensibiUty in accordance ^. V. """P""^"' '^'^ 

with an embodiment of the present invention; ^ ""f'^'='»°° » °f components m 

/ . a financial system; 

FIG, 129 iUustrates widgets with their vahdation require- ™^ ^e-^ *•« . . 

jjjgjjjg, FIG. 154 iUustrates a user manger/user context relation- 

FIG. 130 iUustrates a user interface vaUdator association ^^j?!?^^',. « , ^ . , 

diagram; iUustrates a flowchart for a method for trans- 

TTtr^ ^'a-i Mu *_ * I'j 1 1 J* lating an object attribute to and from a database value in 

FIG. 131 illustrates a vahdation rule class diagram; ^ u j- . r *u 

rrr- la-* 11 * * i t j - . . ... accordance With an embodiment of Uie present mveution; 

FIG. 132 iUustrates a rule validaUon mteracUon diagram; ™^ -« * * .v . ^ / 

iTir- t«;ii„-t«*„«fl u *u - 45 J^^- iUustrates that an attribute cannot be saved 

FIG. 133 lUustratesa flow^art for a method for assigmng ^ persistent store; 

a view to an activity in accordance with an embodiment of ^ \. ... _ 

Uie present invention; iUustrates the use of an Attribute Converter to 

xnn * u- u *u • . • save an attribute into a database; 

FIG. 134 iUustrates a manner m which the maintam _ _ .„ 
customer activity operation of the present invention FIG- 158 iUustrates a flowchart for a method for control- 
launches its view; S ^^^^ ^° accordance with an embodiment of the present 

HG. 135 iUustrates the view configure launching the invention, 

maintain customer view operation; 159 Uhistrates the data retrieval mechanism caUs 

FIG. 136 Ulustrates a flowchart for a method for testing ^"^^ ^^"""^ ^""^ 

successfulness of an operation having pre-conditions and 160 shows the interrelationship between a database, 

post-conditions that must be satisfied for the operation to be a persist, and an account; 

successful in accordance with an embodiment of the present FIG. 161 iUustrates that the database retrieval mechanism 

invention; is separated from the business object by encapsulating the 

FIG. 137 iUustrates an operation diagram depicting an ^^^^ a data handler, 
example of pre-conditions and post-conditions; ^ FIG. 162 iUustrates the UPersistenceStream and TiMap- 

FIG. 138 iUustrates a flowchart for a method for detecting P^"* ^ embodiment of the present invention; 

an orphaned server context in accordance with an embodi- FIG. 163 iUustrates a flowchart for a method for organiz- 

ment of the present invention; ing data access among a plurality of business entities in 

FIG. 139 illustrates a CUent 1 that has instantiated A and accordance with an embodiment of the present invention; 
C, deletes C but fails to delete A; 65 FIG. 164 Ulustrates retrieving data piecemeal; 

FIG. 140 Ulustrates a GarbageCollector requesting for FIG. 165 iUustrates the manner in M\duch the present 

interest in context A; invention retrieves whole objects; 
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FIG. 166 illustrates a flowchart for a method for retrieving units of work for helping prevent the logical units of work 

multiple business objects across a network in one access from interfering with each other in accordance with an 

operation in accordance with an embodiment of the present embodiment of the present invention; 

invention; pjG, 192 illustrates the MVC Implementation with Global 

FIG. 167 illustrates an example of an implementation of ^ Model; 

the Multi-Fetch Object; FIG. 193 illustrates the Separate Models for Separate 

FIG. 168 illustrates the Fetching of a Household object Business LUWs; 

along with the other related objects using the multi object FIG. 194 illustrates the Canceling of one LUW Indepen- 

fetch results; dently of Another LUW; and 

FIG. 169 is an interaction diagram showing when the FIG. 195 illustrates the Context Copying Protects Context 

multi object fetch is not used; Boundaries. 

FIG. 170 illustrates a flowchart for a method for imple- T^T^r^^r^^^ t^^„™ 

menting an association of business objects without retriev- 

ing the business objects from a database on which the 15 FRbFbRRED EMBODIMENTS 

business objects are stored in accordance with an embodi- A preferred embodiment of a system in accordance with 

ment of the present invention; the present invention is preferably practiced in the context of 

FIG. 171 illustrates a flowchart for a method for mapping * personal computer such as an IBM compatible personal 

of retrieved data into objects in accordance with an embodi- computer, ^ple Macintosh computer or UNIX based work- 
ment of the present invention; 20 station. A representative hardware environment is depicted 

FIG. 172 illustrates an Object Identity Cache in accor- i° /IG. 1, which ilhistrates a typical hardware configuration 

dance with one embodiment of the present invention; f * workstation in accordance with a preferred embodiment 

HG. 173 illustrates a flowchart for a method for separat- ii:;°U..^r"l'i^ ™i^/°f T"' ®- T^*" h 

, . J J ^ . - J 1 microprocessor, and a number of other units mterconnected 

mg lope and daUi access concerns during devd^^^^ ^ / ^ workstation shown in FIG. 1 

persis^nt object for msulatmg development of bu^ess ^ includes a Random Access Memory (RAM) 114, Read Only 

logicfiomde>jlopmeDtofdataac^ Memory (ROM) 116, an I/O adapter 118 for connecting 

with an embodiment of the present mvention; peripheral devices suJh as disk stooge units 120 to the b^ 

FIG. 174 illustrates a flowchart for a method for providing 112, a user interface adapter 122 for connecting a keyboard 

a warmng upon retrieval of d>jects that are incomplete in 124, a mouse 126, a speaker 128, a microphone 132, and/or 

accordance with an embodiment of the present invention; other user interface devices such as a touch screen (not 

FIG. 175 illustrates an Entity-Based Data Access System; shown) to the bus 112, communication adapter 134 for 

FIG. 176 iUustrates a Retrieving Data Piecemeal System; connecting the workstation to a communication network 

no. 177 iUustrates a Commit and Rollbadc routine; ^ processing network) and a display adapter 136 

FIG. 178 iUustrates Nested Logical Units of Work; ^'J^T*^? the bus 112 to a display device 138. The 

^ ^ workstation typically has resident thereon an operating 

FIG. 179 illustrates a flowchart for a method for aUowing system such as the Microsoft Windows NT or Window5/95 

a batched request to mdicate that it depends on the response Operating System (OS), the IBM OS/2 operating system, the 

to another request m accordance with an embodiment of the MAC OS, or UNIX operating system. Those skiUed in the 

present mvention; 40 art will appreciate that the present invention may also be 

FIG. 180 illustrates a Batching Retrievals and Depen- implemented on platforms and operating systems other than 

dency; those mentioned. 

FIG. 181 illustrates the Dynamically Setting Dependency; A preferred embodiment is written using JA\^ C, and the 

FIG. 182 illustrates a flowchart for a method for sending language and utflizes object oriented programming 

a single message to aU objects in a logical unit of work in 45 methodology. Object oriented programming (OOP) has 

accordance with an embodiment of the present invention; become increasingly used to develop complex appUcations. 

HG. 183 iUustrates a Hand-crafted Message Forwarding ^s OOP moves toward the mainstream of software design 

scheme* ^ development, various software solutions require adap- 

jnr- \oA 11 *- * • ^ r ^tion to make use of the benefits of OOP. A need exists for 

FIG. 184 iUustrates a Generic Message Forwardmg fea- ^„ p r-^mn * u 1,1 * 

^ ^50 these principles of OOP to be apphed to a messaging 

interface of an electronic messaging system such that a set 

HG. 185 iUustrates a flowchart for a method for batching of OOP classes and objects for the messaging interface can 

logical requests for reducing network traffic in accordance be provided 

with an embodiment of the present invention; qOP is a process of developing computer software using 

FIG. 186 aiustrates the manner in whidi the present 55 objects, including the steps of analyzing the problem, 

invention sends requests independenUy; designing the system, and constructing the program. An 

FIG. 187 iUustrates a manner in which the present inven- object is a software package that contains both data and a 

tion registers requests; collection of related structures and procedures. Since it 

HG. 188 iUustrates a flowchart for a method for sorting contains both data and a collection of structures and 

requests that are being unbatched from a batched message in ^ procedures, it can be visualized as a self-sufficient compo- 

accordance with an embodiment of the present invention; '^^^ require other additional structures, pro- 

HG. 189 iUustrates an Ad Hoc Registration feature; ' '^'''^^ ''^^^ ^^"""^ specific task. OOP, therefore, 

.„ _ ■ , . . Views a computer program as a coUection of largely autono- 

HG. 190 JliKfrates a manner m which the present inven- ^ous components. caUed objects, each of which is lespon- 

Uon sorts requests by weight; 55 sibk for a specific task. This concept of packaging data. 

FIG. 191 illustrates a flowchart for a method for assigning structures, and procedures together in one component or 

independent copies of business data to concurrent logical module is called encapsulation. 
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In general, OOP components are reusable software mod- Objects can represent elements of the computer-user 

ules which present an interface that conforms to an object environment such as windows, menus or graphics 

model and which are accessed at run-time through a com- objects. 

ponent integration architecture. A component integration An object can represent an inventory, such as a personnel 

architecture is a set of architecture mechanisms which allow 5 file or a table of the latitudes and longitudes of cities, 

software modules in d^erent proc^ spaces to utili^ each ^ ^ ^r-defined data types such as 

others capabihties or fiincUons. 1^ is generally done by ^ 

assuming a common component object model on which to olane 

build the architecture. It is worthwhile to differentiate nr^u *l- r i_- * * 

. ^ 1 ..t_- . A With this enormous capabihty of an object to represent 

between an object and a class of objects at this pomt. An lo • . . . i • n ui .* n 

, . _^ . . 1 • . i?.. 1 J? i_. . , • . . just about any logically separable matters, OOP aUows the 

obiect IS a smgle instance oi the class of obiects, which is j i^ j* j-i 

J , t A 1 s u- . u J software developer to design and implement a computer 

often just called a class^ Aclass of objects can be viewed as ^ ^ ^^^j ^^^^^^ 

a blueprint, from which many objects can be formed. ^^^^ ^ ^ ^^^^^^ ^^^^^^ ^ ^ ^^l^^^^ ^ 

OOP allows the programmer to create an object that is a composition of matter. Since the object can represent 
part of another object. For example, the object representing 15 anything, the software developer can create an object which 

a piston engine is said to have a composition-relationship can be used as a component in a larger software project in 

with the object representing a piston. In reality, a piston future. 

engine comprises a piston, valves and many other compo- if 90% of a new OOP software program consists of 

nents; the fact that a piston is an element of a piston engine proven, existing components made fiom preexisting reus- 
can be logicaUy and semantically represented in OOP by two 20 ^^^^ dsjects, then only the remaining 10% of the new 

objects. software project has to be written and tested from scratch. 

OOP also allows creation of an object that "depends Since 90% already came from an inventory of extensively 

from" another object. If there are two objects, one repre- tested reusable objects, the potential domain from which an 

senting a piston engine and the other representing a piston error could originate is 10% of the program. As a result, 
engine wherein the piston is made of ceramic, then the ^ OOP enables software developers to build objects out of 

relationship between the two objects is not that of compo- other, previously built objects. 

sition. A ceramic piston engine does not make up a piston This process closely resembles complex machinery being 

engine. Rather it is merely one kind ofpiston engine that has built out of assemblies and sub- assemblies. OOP 

one more limitation than the piston engine; its piston is made technology, therefore, makes software engineering more like 

of ceramic. In this case, the object representing the ceramic hardware engineering in that software is built from existing 

piston engine is called a derived object, and it inherits all of components, which are available to the developer as objects, 

the aspects of the object representing the piston engine and All this adds up to an improved quality of the software as 

adds further limitation or detail to it. The object representing well as an increased speed of its development, 

the ceramic piston engine "depends from" the d>ject repre- Programming languages are begirming to fully support the 

senting the piston engine. Hie relation^ip between these OOP principles, such as encapsulation, inheritance, 

objects is called inheritance. polymorphism, and composition-relationship. With the 

When the object or class representing the ceramic piston advent of the C++ language, many commercial software 

engine inherits all of the aspects of the objects representing developers have embraced OOP. C++ is an OOP language 

the piston engine, it inherits the thermal characteristics of a ^ offers a fast, machine-executable code. Furthermore, 

standard piston defined in the piston engine class. However, C++ is suitable for both commercial-application and 

the ceramic piston engine object overrides these ceramic systems-programming projects. For now, C++ appears to be 

specific thermal characteristics, which are typically different the most popular choice among many OOP programmers, 

from those associated with a metal piston. It skips over the there is a host of other OOP languages, such as 

original and uses new ftmctions related to ceramic pistons. SmalUalk, Common lisp Object System (CLOS), and Eiffel. 

Different kinds of piston engines have different Adt^tionally, OOP capabilities are being added to more 

characteristics, but may have the same underlying functions traditional popular computer programming languages such 

associated with it (e.g., how many pistons in the engine, as Pascal. 

ignition sequences, lubrication, etc.). To access each of these The benefits of object classes can be sununarized, as 

functions in any piston engine object, a programmer would follows: 

call the same fiinctions with the same names, but each type Objects and their corresponding classes break down com- 

of piston engine may have different/overriding implemen- plex programming problems into many smaller, sim- 

tations of ftmctions behind the same name. This ability to pier problems. 

hide different implementations of a function behind the same Encapsulation enforces data abstraction through the orga- 

name is called polymorphism and it greaUy simplifies com- nization of daU into small, independent objects that can 

munication among objects. communicate with each other. Encapsulation protects 

With the concepts of composition-relationship, the data in an object from accidental damage, but 

encapsulation, inheritance and polymorphism, an object can allows other objects to interact with that data by calling 

represent just about anything in the real world. In fact, one's the object's member ftmctions and structures, 
logical perception of the reality is the only limit on deter- ^ Subclassing and inheritance make it possible to extend 

mining the kinds of things that can become objects in and modify objects through deriving new kinds of 

object-oriented software. Some typical categories are as objects from the standard classes available in the sys- 

foUows: lem. Thus, new capabilities are created without having 

Objects can represent physical objects, such as automo- to start from scratch. 

biles in a traffic-flow simulation, electrical components 65 Polymorphism and multiple inheritance make it possible 
in a circuit-design program, countries in an economics for different programmers to mix and match character- 
model, or aircraft in an air-traffic-control system. istics of many different classes and create specialized 
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objects that can still work with related objects in 
predictable ways. 
Qass hierarchies and containment hierarchies provide a 
flexible mechanism for modeling real-world objects 
and the relationships among them, 
libraries of reusable classes are useful in many situations, 

but they also have some limitations. For example: 
Complexity. In a complex system, the class hierarchies for 
related classes can become extremely confusing, with 
many dozens or even hundreds of classes. 
Flow of control. A program written with the aid of class 
libraries is stiU responsible for the flow of control (i.e., 
it must control the interactions among all the objects 
created from a particular library). The programmer has 
to decide which fimctions to caU at what times for 
which kinds of objects. 
Duplication of effort. Although class libraries allow pro- 
grammers to use and reuse many small pieces of code, 
each programmer puts those pieces together in a dif- 
ferent way. Two different programmers can use the 
same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure 
(i.e., design) may be quite different, depending on 
hundreds of small decisions each programmer makes 
along the way. Inevitably, similar pieces of code end up 
doing similar things in slightly different ways and do 
not work as well together as they should. 
Class libraries are very flexible. As programs grow more 
complex, more programmers are forced to reinvent basic 
solutions to basic problems over and over again. A relatively 
new extension of the class library concept is to have a 
framework of class libraries. This framework is more com- 
plex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major 
mechanics that implement the common requirements and 
design in a specific application domain. TTiey were first 
developed to free application programmers firom the chores 
involved in displaying menus, windows, dialog boxes^ and 
other standard user interface elements for personal comput- 
ers. 

Frameworks also represent a change in the way program- 
mers think about the interaction between the code they write 
and code written by others. In the early days of procedural 
programming, the programmer called libraries provided by 
the operating system to perform certain tasks, but basically 
the program executed down the page from start to finish, and 
the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems 
with a program that executed in just one way. 

Tbe development of graphical user interfaces began to 
turn this procedural programming arrangement inside out. 
These interfaces allow the user, rather than program logic, to 
drive the program and decide when certain actions should be 
performed. Today, most personal computer software accom- 
plishes this by means of an event loop which monitors the 
mouse, keyboard, and other sources of external events and 
calls the appropriate parts of the programmer's code accord- 
ing to actions that the user performs. The programmer no 
longer determines the order in which events occur. Instead, 
a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relin- 
quishing control in this way to users, the developer creates 
a program that is much easier to use. Nevertheless, indi- 
vidual pieces of the program written by the developer still 
call libraries provided by the operating system to accomplish 
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certain tasks, and the programmer must still determine the 
flow of control within each piece after it's called by the 
event loop, ^plication code stiU "sits on top of* the system. 

Even event loop programs require programmers to write 
a lot of code that should not need to be written separately for 
every application. The concept of an application fr^cwoik 
carries the event loop concept further. Instead of dealing 
with all the nuts and bolts of constructing basic menus, 
windows, and dialog boxes and then making these things all 
work together, programmers using application frameworks 
start with working application code and basic user interface 
elements in place. Subsequently, they build from there by 
replacing some of the generic capabilities of the framework 
with the specific capabilities of the intended application. 

y^plication frameworks reduce the total amount of code 
that a programmer has to write from scratdi. However, 
because tbe framework is really a generic application that 
displays windows, supports copy and paste, and so on, the 
programmer can also relinquish control to a greater degree 
than event loop programs permit. The framework code takes 
care of almost all event handling and flow of control, and the 
programmer's code is called only when the framework 
needs it (e.g., to create or manipulate a proprietary data 
stmcture). 

A programmer writing a framework program not only 
relinquishes control to the user (as is also true for event loop 
programs), but also relinquishes the detailed flow of control 
within the program to the framework. This approach allows 
the creation of more complex systems that work together in 
interesting ways, as opposed to isolated programs, having 
custom code, being created over and over again for similar 
problems. 

Thus, as is explained above, a framework basically is a 
collection of cooperating classes that make up a reusable 
design solution for a given problem domain. It typically 
includes objects that provide default behavior (e.g., for 
menus and windows), and programmers use it by inheriting 
some of that default behavior and overriding other behavior 
so that the framework calls application code at the appro- 
priate times. 

There are three main differences between frameworks and 
class Libraries: 

Behavior versus protocol. Qass libraries are essentiaUy 
collections of behaviors that you can caU when you 
want those individual behaviors in your program. A 
framework, on the other hand, provides not only behav- 
ior but also the protocol or set of rules that govern the 
ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide 
versus what the framework provides. 

Call versus override. With a class library, the code the 
programmer instantiates objects and calls their member 
functions. It's possible to instantiate and call objects in 
the same way with a framework (i.e., to treat the 
framework as a class library), but to take full advantage 
of a framework's reusable design, a programmer typi- 
cally writes code that overrides and is called by the 
framework. The framework manages the flow of con- 
trol among its objects. Writing a program involves 
dividing responsibilities among the various pieces of 
software that are called by the framework rather than 
specifying how the different pieces should work 
together. 

Implementation versus design. With class libraries, pro- 
grammers reuse only implementations, whereas with 
frameworks, they reuse design. A framework embodies 
the way a family of related programs or pieces of 
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software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in 
a given domain. For example, a single framework can 
embody the way a user interface works, even though 
two different user interfaces created with the same 5 
framework might solve quite different interface prob- 
lems. 

Thus, through the development of frameworks for solu- 
tions to various problems and programming tasks, signifi- 
cant reductions in the design and development effort for lo 
software can be achieved. A preferred embodiment of the 
invention utilizes HyperText Markup Language (HTML) to 
implement documents on the Internet together with a 
general-purpose secure communication protocol for a trans- 
port medium between the client and the Newco. HTTP or 15 
other protocols could be readily substituted for HTML 
without undue experimentation. Information on these prod- 
ucts is available in T. Bemers-Lee, D. Connoly, "RFC 1866: 
Hypertext Markup Language — 2.0" (November 1995); and 
R. Fielding, H, Frystyk, T. Bemers-Lee, J. Gettys and J. C. 20 
Mogul, "Hypertext Transfer Protocol— HTTP/1.1: HTTP 
Working Group Internet Draft" (May 2, 1996). HTML is a 
simple data format used to create hypertext documents that 
are portable from one platform to another. HTML docu- 
ments are SGML documents with generic semantics that are 25 
appropriate for representing information from a wide range 
of domains. HTML has been in use by the World- Wde Web 
global information initiative since 1990. HTML is an appli- 
cation of ISO Standard 8879; 1986 Information Processing 
Text and Office Systems; Standard Generalized Markup 30 
Language (SGML). 

To date, Web development tools have been limited in their 
abUity to create dynamic Web apphcations which span from 
client to server and interoperate with existing computing 
resources. Until recenUy, HTML has been the dominant 35 
technology used in development of Web-based solutions. 
However, HTML has proven to be inadequate in the fol- 
lowing areas: 

Poor performance; 

Restricted user interface capabilities; ^ 
Can only produce static Web page^ 
Lack of interoperability with existing applications and 
data; and 

Inability to scale. ^5 

Sun Microsystem's Java language solves many of the 
client-side problems by: 

Improving performance on the client side; 

Enabling the creation of dynamic, real-time Web appli- 
cations; and 50 

Providing the ability to create a wide variety of user 
interface components. 

V/iih Java, developers can create robust User Interface 
(UI) components. Custom "widgets" (e.g., real-time stock 
tickers, animated icons, etc.) can be created, and client-side 55 
performance is improved. Unlike HTML, Java supports the 
notion of client-side validation, offloading appropriate pro- 
cessing onto the client for improved performance. Dynamic, 
real-time Web pages can be created. Using the above- 
mentioned custom UI components, dynamic Web pages can 60 
also be created. 

Sun's Java language has emerged as an industry- 
recognized language for "programming the Internet" Sun 
defines Java as: "a simple, object-oriented, distributed, 
interpreted, robust, secure, architecture-neutral, portable, 65 
high-performance, multithreaded, dynamic, buzzword- 
compliant, general-purpose programming language. Java 
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supports programming for the Internet in the form of 
platiform-independent Java applets." Java applets are small, 
specialized applications that comply with Sun's Java >^pli- 
cation Programming Interface (API) allowing developers to 
add "interactive content" to Web documents (e.g., simple 
animations, page adornments, basic games, etc.). .^iplets 
execute within a Java-compatible browser (e.g., Netscape 
Navigator) by copying code from the server to client. From 
a language standpoint, Java's core feature set is based on 
C++. Sun's Java hterature states that Java is basically, "C++ 
with extensions from Objective C for more dynamic method 
resolution." 

Another technology that provides similar function to 
JAVA is provided by Microsoft and ActiveX Technologies, 
to give developers and Web designers wherewithal to build 
dynamic content for the Internet and personal computers. 
ActiveX includes tools for developing animation, 3-D vir- 
tual reahty, video and other multimedia content. The tools 
use Internet standards, work on multiple platforms, and are 
being supported by over 100 companies. The group's build- 
ing blocks are called ActiveX Controls, small, fast compo- 
nents that enable developers to embed parts of software in 
hypertext markup language (HTML) pages. ActiveX Con- 
trols work with a variety of programming languages includ- 
ing Microsoft \^al C++, Borland Delphi, Microsoft A^al 
Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, 
allowing developers to create server applications. One of 
ordinary skill in the art readily recognizes that ActiveX 
could be substituted for JAVA without undue experimenta- 
tion to practice the invention. 
Overview 

Architecture Basics 
Architecture Ovenaew 
What is architecture? 

Architecture — whether the word is applied to work with 
a city skyline or an information system — is both about 
designing something and about making, building, or con- 
structing something. An architect is literally a ''master 
builder" — from the Greek words archi (primary or master) 
and tekton (builder or carpenter). In good Greek fashion, 
however, it would be unthinkable for something to be built 
without a sound theoretical basis. So architecture involves 
theory, but there is nothing merely theoretical about it. 
Conversely, architecture is also eminendy practical, but 
there is nothing merely practical about it. Ideas about form 
and structure lie behind architecture. Ultimately one must let 
go of a mindset that tries to separate the designing from the 
making; they exist together as a whole, and to extract one 
without the other is to kill the whole. 

Architecture also is an engineering discipline. It creates 
and also depends on a structured marmer to analyze and 
design whatever is to be built. Like all living disciplines, 
architecture continues to grow and evolve. Engineering 
discoveries move the field forward. Certain design and 
engineering principles clearly show themselves to be suc- 
cessful in practice, and these then become repeatable com- 
ponents of additional work. The ability to continue to master 
each component, as well as the interrelations among 
components, is a distinguishing characteristic of architec- 
ture. 

So architecture is about designing and building something 
from a set of basic components, and also about the interre- 
lations among the components. And it is a discipline 
whereby all these things come together — materials, space, 
people — to bring something into being that was not there 
before. 
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Although building architects have not always been 
pleased about it, architectural concepts have influenced 
other kinds of "building** projects for some time. Over the 
past twenty yeais, developers of information systems, for 
example, have used concepts from the field of architecture 
not only to describe their work but to execute it, as well. 

The use of architectural thinking implies that the work is 
about creating certain kinds of structures that can be engi- 
neered or at least influenced, and that the work can be 
organized and performed in a structured, systematic manner. 
Moreover, use of architectural concepts implies that there is 
something repeatable about the work: architects can create a 
structure, then use components of that structure again in the 
future when they come across a similar situation. 

An architectural paradigm should not be Ughdy used. It 
makes demands. To use architectural concepts imphes that 
clients are ready to do so—that is, that the field is sufSciendy 
mature in its work to see patterns and to organize future 
work according to those patterns. 

Finally, architecture must be understood as a process 200, 
not just a thing. This process can be described at a very high 
level using FIG. 2. 

Step 1: Analyze 202. The architect must begin by listening 
to and researching the needs of the client. What is the 
function of the building? What is its environment? 
What are the limitations set by budget and use? 
Step 2: Design 204. This is a blueprint stage. The architect 
creates one or several designs showing the layout of the 
structure, how different spaces fit together, how every- 
thing looks from different views, what materials are to 
be used, and so forth. 
Step 3: Model & Test 206. Not every architectural project 
has this step, but in many cases, the architect will create 
a scale model/prototype of the finished prcxhict, allow- 
ing the client a clearer sense of what the ultimate 
solution will look like. A model is a kind of test stage, 
allowing everyone to test the design in a near-real-life 
setting. 

Step 4: Build 208. This is the actual construction of the 
building, in general accord with the blueprints and 
prototype. 

Step 5; Operate and Evolve 210. The building is to be 
lived in and used, of course, and so an important step 
is to ensure that the finished product is tended and 
operated effectively. Architects themselves may not be 
involved in the operation of their building, but they 
certainly would be involved in future expansions or 
evolutions of the building. Stewart Brand's recent text. 
How Buildings Learn, argues that effecdve architecture 
takes into account the fact that buildings "learn": as 
people live and work in them over time, those people 
will seek to alter the building in subtle, or not so subtle, 
ways. 

Also, when architects design a building, they have in their 
heads a primary conceptual framework for all the compo- 
nents that go into that building: the plumbing, the electric, 
the sewers, stairs/elevators, framing structure, and so forth. 
The tadt step for an architect is, "Based on my knowledge 
of the generic components that go into a building, how will 
these components fit together in this particular building? 
Which of these components will require fecial attention 
because of the functional demands of the building?" 
Oxford English Dictionary Definition 
The conceptual structure and overall logical organization 
of a computer or computer-based system from the point 
of view of its use or design; a particular realization of 
this. 
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Gartner Group Definition 

The manner or structure in which hardware or software is 
constructed. Defines how a system or program is 
structured, how various components and parts interact, 
as well as what protocols and interfaces are used for 
communication and cooperation between modules and 
components which make up the system. 

Gartner Group sets forth seven general characteristics of 
successful architectures. 

Delimitation of the problem to be addressed 

Decomposition of the solution to components with clearly 
assigned responsibilities 

Definition of interfaces, formats, and protocols to be used 
between the components. These should be sufficiendy 
clear and robust in order to permit asynchronous devel- 
opment and ongoing reimplementation of the compo- 
nents. 

Adequate documentation to permit compliance by imple- 
mentors 

An auditing mechanism fliat exercises the specified inter- 
faces to verify that specified inputs to components yield 
specified results 

An extendibility mechanism to enable response to chang- 
ing requirements and technologies 

Policies, practices, and organizational structures that 
facilitate adoption of the architecture 

What types of architectures are discussed in the following 
description? 

Standard Architecture Framework (SAF) 300 provides 
access to the user's thought leadership and architecture 
frameworks for Execution, Development and Operations 
environments 302, 304, 306. For a more detailed discussion 
on these architectures, please see Standard Ardiitecture 
Summaries (below). FIG. 3 shows the dependencies of the 
three architecture frameworks and is described in more 
detail in the Dehvery Vehicle Overview (below). 

The following lists are starting points for considering the 
range of components and activities that must be covered by 
each architectural view of the system. They are not a 
definitions of the environments. 
Standard Ardutecture Summaries 
Execution Architecture 302 

The execution architecture is a unified collection of 
run-time technology services, control structures, and sup- 
porting infrastructure upon which apphcation software runs. 

It includes components such as: 

Application messaging 

Batch processing architecture 

Middleware 

Reporting 

Error handling 

On-line architecture 

Security 

Code/decode 

Data access methods 

Integrated help 

File transfer capabilities 

Directory services 

Load balancing 

Workflow services 

State management 

"Special" requirements (e.g., workflow, telephony, 
groupware) 



us 6,636^42 B2 



19 



20 



Developmeot Archilecture Framework 304 

The Development Architecture Framewoik (DAF) is a 
unified coUectioa of technology services, tools, techniques, 
and standards for constructing and maintaining application 
software. 

It includes components such as: 

Design/documentation tools 

Information repository 

Project Management tools 

Program Shells 

GUI Window painter 

Prototyping tools 

Programmer APIs 

Testing tools 

Source code control/build process 

Performance test tools 

Productivity tools 

Design tools 

Compiler/debugger 

Editor 

Refer to the Development Architecture Framework appU- 
cation (referenced above) for more Information 
Operations Architecture 306 

A unified collection of technology services, tools, stan- 
dards and controls required to keep a business application 
production or development enviroiunent operating at the 
designed service leveL It di£fers from an execution archi- 
tecture in that its primary users are system administrators 
and production support personnel. 

It includes components such as: 

Job scheduler 

Software distribution 

Error monitor 

Data backup and restore 

Help desk 

Security administration 

High-AvailabiUty 

Hardware management 

Performance monitors 

Startup/shutdown procedures 

Report management tool 

Disaster Recovery 

Network Monitoring Tools 

Cross Platform Management Tools 
Considerations — All Environments 

To ensure that you are asking the right questions about the 
technology architecture, you must refer to the Architecture 
Checklist (available from the Content Finder). Questions 
win include: 

For all technology components, have the following char- 
acteristics been addressed: 

Performance according to specifications? 
Rehability of operation? 
Ease of operation? 
Maintenance requirements? 

Ability to interface with other components, particularly 

those from other vendors? 
Delivery schedule to provide adequate prc-conversion 

testing? 
Backup procedures? 
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Vendor reliability and financial stability? 

Future proofing against business change? 

Have the versions of system software been live at another 
site for at least six to twelve months? 

This time frame varies by product. Have reference sites 
been verified? 

What is a framework? 

It is a major challenge to design the complex infrastruc- 
ture that is needed to satisfy the requirements of today's 
distributed, mission-critical applications. As such, it is help- 
ful to have an inventory of ie components thai may be 
required for the design, build, installation and operation of 
systems. It is also helpfiil to have an imderstanding of how 
the components fit together conceptually. 

A Framework should be thought of as a conceptual 
stmcture used to frame the work about to be done. It should 
be used as a thought trigger or as a completeness check. You 
cannot build from a framework directly but instead should 
use it as a starting point for understanding and designing. 

Frameworks are used to help practitioners understand 
what components may be required and how the components 
fit together. Based on the inventory of components and the 
description of their relationships, practitioners wiU select the 
necessary components for their design. An architect extracts 
components from one or more Frameworks to meet a 
specific set of user or application requirements. Once an 
architecture has been implemented it is often referred to as 
an architecture or an infrastructure. 

The scope of what a framework addresses can vary 
widely. One framework, for instance, may outline the com- 
ponents for a technical infrastructure in its entirety whereas 
another framework may focus explicitly on the network. A 
thorough understanding of a framework's scope is crucial to 
its use during the design phase of a project. 

It is also important to understand whether the fr^ewoik 
is vendor specific in nature (proprietary) or whether it is 
available for use by a large number of vendors (open). 

Why is architecture important? 

One has seen the benefits of an architectural approach to 
information systems development: better productivity and 
less reinvention of the wheel. An architecture provides a 
completeness check, ensuring that all relevant components 
of a possible solution have been considered. It ensures 
consistent, reliable, high-quality applications. It gives 
everyone — the developers and their chents — a common 
framework and common language with which to talk about 
the work. 

Perhaps most important, it allows developers to leverage 
successful solutions when performing additional work. 
Architecture involves repeatable concepts, and so it reduces 
the time arnl cost by which a solution is cklivered. 

Some of the specific technical benefits of a good archi- 
tecture are: 

Simplified implication Development 

Provides common set of application services. Removes 
application progranuners from the complexities of the 
underlying technology and development tools, allow- 
ing less experienced developers to be more productive. 

Quality 

Usually more experienced developers implement the 
often complex technical components in an architecture. 
These components are then reused, avoiding duplicated 
complex logic in the applications. Iterations during 
design, implementation and testing often result in 
refinement and improvement of the architecture com- 
ponents. All users of these components benefit from 
such improvements, reducing the risk of failure and 
ensuring better overall quality in the final application. 
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Integration 

An architecture often ties together disparate software, 
platforms and protocols into one comprehensive frame- 
work. 
Extensibility 

The architecture is established by experienced personnel 
who can predict with some confidence whether a given 
architecture will fulfill current and future requirements. 
Code extensions are easily integrated. A well-balanced 
architecture consists of the "right" components, where 
the components are tied together by simple 
interrelationships, since complex relationships increase 
the architecture's complexity faster than modulariza- 
tion can reduce it. 

Location Transparency 

Divorces application from the details of resource location. 
This is however not always true or required. For 
performance reasons designers and developers still 
often need to be aware of process and data locations. 

Horizontal Scaling 

Assist in optimal utilization of existing infrastructure 
resulting in increased application performance and sta- 
bility. 

Isolation 

An architecture can be used to isolate the applications 
from particular products. This ensures that products can 
more easily be replaced later. Hiis characteristic can be 
important if there is risk associated with a product's or 
product vendor's future, or the rate of change in a 
particular technology area is particularly high. An evi- 
dent example is looking back at changes in past user 
interface standards. .^Tplications that did not separate 
user interface logic from business logic, had to be 
completely rewritten to take advantage of new user 
interfaces, such as MS Endows and more recently 
Web browsers. 
Portability 

Increases portability and reusability within and across 
different platforms or protocols. 

The use of architecture frameworks during analysis and 
design can reduce the risks of an IT solution. It should 
improve development productivity through reuse, as well as 
the IT solution's reliability and maintainability. 

One key challenge for today's IT managers is the need for 
change. Architectures provide a basic framework for major 
change initiatives. Clients' core business is performed by 
strategic applications that will most likely require frequent 
and rapid development to handle changes in technology 
capabiUty and business requirements. A properly defined 
and intelligently developed architecture dehvers an infra- 
structure on which clients can build and enhance applica- 
tions that support their current and future business needs. 
This is how one helps clients to manage diange. 

A key benefit of an architecture is that it divides and 
conquers complexity. Simple applications benefit less from 
architecture than complex ones do; fewer decisions are 
needed in these cases, and fewer people need to know about 
them. During maintenance, a poorly architected small appli- 
cation is tolerable because it is still relatively easy to locate 
a fault and to anticipate the side effects of correcting it. 
Conversely, complex applications are more difficult to 
imderstand and to modify. Complexity is reduced by sub- 
dividing the application in layers and components, each 
layer having a specific functionality. The layers are strongly 
cohesive and de-coupled: A given layer does iK>t need to 
know the internals of any other layer. 
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The following quote fix)m a recent study of Large Com- 
plex Systems (LCS) stress the importance of a stable archi- 
tectures in large systems: 

Successfid delivery of an LCS solution depends on the 
early definition and use of conomon data applications 
and technology architecture. 

There is a high failure rate when the architecture is not 
defined, stabilized, and delivered early in an LCS effort. 

All significant LCS efforts involved the use of common or 
shared architectures. A successful effort, however, 
depended on early definition and delivery of a stable 
common architecture. 

Significant changes to the data, application, or technology 
architectures had severe negative effects on the time- 
liness of project deliverables, and on the reliability of 
what was delivered. 

PROJECT! and PR0JECT2, for example, experienced 
unusual circumstances. While the client evaluated 
whether to proceed, one defines and designs the archi- 
tecture. As a result, the teams had nine months to 
define, design, and begin implementation of required 
data, applications, and development architectures. 
Although in each case these architectures continued to 
evolve with business and technology needs, they 
remained largely consistent with the initial design. This 
consistency proved to be essential to the timely deliv- 
ery of the applications. 

At PR0JECT3 and PR0JECT4, on the other hand, the 
architectures went through major evolutions as the 
developers created the applications. The overall result 
was that those efforts experienced delays relative to 
plan. 

Although it is not realistic for every project to have nine 
months to define required architectures, it does suggest 
that early focus on definition and design of the archi- 
tectural components is essential. 
The risk of failure is greatly increased if essential archi- 
tectures are being defined or changed significantly in 
parallel with application development. 
What are the benefits of an architecture? 
The benefits derived from a technology architecture may 
allow a user to be in the forefront of the development of 
many leading edge business solutions. The investment in a 
reliable and flexible architecture can result in one or more of 
the following: 

Preservation of investments in applications and technol- 
ogy by isolating each from changes in the other (e.g. 
upgrades in hardware or third-party software do not 
impact applications). 

Leveraging scarce technical skills (e.g. the need for 
people with detailed skills in a specific communications 
protocol or aspects of SQL). 

Enhancements in productivity, flexi*bility and maintain- 
ability because common and often complex and error- 
prone components (e.g. error handling or cross- 
platform communications) are created within the 
architecture, and then reused by all applications. 

Increases in the predictability of application performance 
because the run-time behavior of common components 
is familiar and consistent. 

Serves as a construction blueprint and discussion agenda 
and ensures consistency across systems. This can have 
a big impact on the operability and maintenance of the 
delivered applications. 
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What is an architect? Delivery Vehicle Matrix 

Architects must have deep uxKlerstandiog of a project, FIG. 4 illustrates a delivery vehicle matrix 400. One way 

business and/or technical environment. Architects are of looking at a Delivery Vehicle is therefore as an intersec- 
involved across business integration projects, managing tion of a technology generation 402 and application style 

their complexities and intricacies. 5 404, This is the presentation method currently adopted for 

How advanced should an architect be? navigation in S AF. 

It is easy to go overboard when designing and implement- Delivery Vehicle Cube 

ing a technology architecture. Ideally the architecture ^ould Delivery Vehicle Cube 500, illustrated in FIG. 5, 

be a thin, well-defined layer that ensures development represents the "full** picture of what a Delivery Vehicle is. In 

productivity, maintenance flexibility, performance and sta- lo addition to the implication Styles and the Technology gen- 

bility. erations it introduces a distinction between Execution, 

A key issue is maintainability and operability. Keep in Development and Operations Environments 502^04,506. 

mind that others may have to understand the rationale following dimensions, or cube "faces: 

behind the architecture design in order to correctly maintain 1* On the bottom left face of the cube are the core 

it. 15 technology components and services 508 that are com- 

Architecture logic can quickly become very abstract and nion across all deUvery vehicles, 

hard to maintain by otheis than those who built it. A These core services may be implemented using one or 

carefully designed architecture can quickly be destroyed by several of the Technology Generations; currently Host, 

maintenance personnel that do not understand how it was Client/Server or Netcentric. Most major enterprises have 

designed and developed. 20 legacy systems that include both host based and distributed 

You should make your architecture as light-weight as client/server applications. Netcentric applications may 

possible only addressing the requirements that drive it. extend the mix of system technologies. 

Avoid "nice to have** flexibility and additional levels of 2. On the top left of the cube are the technology compo- 

abstractions that are intellectually interesting but not strictly nents 510 that are required to support a distinct delivery 

required. 25 vehicle, 

Dehvery Vehicle Overview These components extend the technology architecture 

A Delivery Vehicle is an integrated collection of technol- services that are specific for each distinct delivery 

ogy services that supports an application style, implemented vehicle. Some of the components may extend some of the 

on a distinct architecture generation. services. 

Application Style ^ ^- 0° the right face of the cube are the three environments 
An application style defines a unique class of processing ^^^^ deUvery vehicle wiU aflFect: execution, develop- 
type, which is used by applications, and thus end-users. operations 502,504,506. 
Dehvery Vehicle Reference set of y^pUcation Styles inchide services and the delivery vehicle extensions 
batch, on-line transaction processing, collaboration, data reqmre support in all three environments. The cube iUus- 
warehouse, knowledge management and integration. ^^^^ different dehvery vehicles may require different 
Tlie y^phcation Style is the primary dimension of a extensions to a core development or operations 
Delivery Vehicle, and most people use the terms AppUcation environment, not just the execution architecture. A mission- 
Style and Dehvery Vehicle to mean the same thing. "^^'^^^ high-volume transaction delivery vehicle may 
Akey goal with a dehvery vehicle is that it can be reused ^ ^^^^^^^^ performance tuning tools in the development 
across many apphcations. li is stiU part of the Technology ^^^f.^"^' ^.^f ^ ^^-^^ monitormg tools m the 
A U-* *, 4 • 1 • i f: n % ' 7 operations architecture. 
Architecture, not involvmg apphcation specific logic. An AiJir..i.i 

AppUcation Architecture on the other handTwiD be Ako different technology generaUonsmay reqmre special 

for a particular application. ^ environments. When working m a 

..... .. multi-platform enviromnent, there may be dupbcated ser- 

Architecnire Generation ,5 ^i^^^ ^^^^^^ platforms. This usually complicates 

An architecture generaUon is a broad classification development, operations and execution architectures and 

scheme for placmg technology components within a tech- may require special focus on providing an integration archi- 

nology era. DeUvery Vehicles are physicaUy implemented tecture. 

on a distinct architecture generation. Examples of architec- The following figure illustrates the relationship between 

ture generations mclude host-based, client-server and net- 50 the three environments and the overall business system: 

centric. TypicaUy, one may focus on engagements regarding the 

Note: Defining a clear line between what falls under the execution environment. The main dependency between 

cUent/server and a Netcentric technology generation is dif- these three environments is that the execution architecture to 

ficult; typically different people tend to have different opin- a large degree drives the requirements for the development 

ions. TechnologicaUy, the Netcentric generation may be an 55 and operations architectures. For example if a 

evolution of the cUent/server generation. In the context of heterogeneous, distributed execution architecture is 

the Delivery Vehicles, the technology generation discussion selected, both the development and operations environments 

may be intended to be a logical discussion that aims to must reflect this. 

highlight the new business capabiHties enabled by new How can the delivery vehicle framework be useful? 

technologies. So for example, there could be a PowerBuilder 60 Refocus users and cUents toward business solutions and 

application executing from a Web Browser using a plug-in. away from technology issues. 

Whether this is called a cHent/server or Netcentric appHca- Help you link architecture planning dchverables to deliv- 

tion is up to the reader. When presenting technology archi- ering. 

tecture information to clients, focus on the business capa- Create an enterprise-wide view of the business capabili- 

bilities that are offered by technologies rather than just on 65 ties enabled by technologies. 

definitions for what is chent/server or what is Netcentric Provide new architecmre frameworks needed today to 

technology. meet you're a user's chent's business needs. 
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Provide guidance to define what architecture best meets 
you're a user's client's business needs. 

Provide standard architecture frameworks and best prac- 
tices to build these architectures. 

During a high-level architecture design, help the user 
identify architecture services the user will need to address, 
by providing a logical level discussion one can use to assess 
types of base services and products needed for the specific 
situation. 

When Delivery Vehicles are implemented, they reduce 
time to implement business solutions by providing "Starter 
Kits'* architectures. 

When Delivery Afehicles are implemented, they leverages 
technology across the business by: 

reducing operations and maintenance costs by limiting the 
number of different technologies and sidlis required to 
support these technologies. 

reducing technology costs for execution & development. 

Note: The Delivery Vehicle Framework presents a way to 
organize technology architecture information. When pre- 
senting this type of content client, one may need to tailor the 
information they present based on the client's background 
and the terminology they are familiar with. 
Technology Generation Selection 
Introduction 

Ibis section should assist an architect in understanding 
the characteristics of, and the implications from selecting, a 
specific technology generation. The strengths and weak- 
nesses of each technology generation should be understood 
when planning and designing a system. When identifying 
the core technologies to be used in an architecture, a view of 
the client's existing IT architecture 600, guiding principles 
602 and business imperatives 604 should be taken into 
consideration, as depicted in FIG. 6. 

It is important to realize that a distinct, static division does 
not exist between the different tedmology generations. It is 
possible that an architecture may consist of components 
from more than one generation. 

The goal should be to understand the pros and cons of the 
different technology options available for each component 
and to select the most appropriate one based on the client's 
requirements. 

It is becoming more important to leverage existing sys- 
tems and integrate them with new applications. A typical 
scenario can involve mainframe legacy systems acting as 
servers in a client server architecture, application servers 
being accessed from both traditional GUI clients built in 
Powerbuilder and WisuA Basic and from Web-based front 
ends accessing the application servers via a Web-server. 
General Considerations 

From a technology point of view a new custom-made 
application should generally use the most recent Architec- 
ture Generation to assiire that the application will live longer 
by better being able to adapt to fiiture changes. 

This implies that most apphcations should ideally be 
based on a Netcentric Architecture, rather than on a tradi- 
tional client/server or a host-based architecture. 

However choosing a generation is not just a technical 
decision. Often key technology architecture decisions are 
made as a result of factors which are completely non- 
technical in nature, such as financial factors, internal and 
client politics (say no more), and implementation/ 
operational considerations. 

When deciding whether to employ a Netcentric solution, 
i.e. incorporating Web-based user interfaces and Internet 
application styles, keep in mind that these technologies are 
not a panacea and should be used only when there is soHd 
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business reason. They require new investments in skills, 
tools, development and operations processes. Due to the 
relative immaturity of tools and products, they also represent 
additional risks both in technical terms, such as performance 
and reliability, and in strategic terms, such as vendor and 
product quality and stability. 

Regardless today each project should always consider the 
prospect of utilizing Netcentric technologies. It is important 
to evaluate whether the application can benefit from a 
Netcentric style implementation immediately or in the 
future. 

Even if a traditional client/server approach (e.g. using 
Visual Basic or PowerBuilder) is decided upon, the use of 
Netcentric concepts to produce significant reductions in 
software packaging and distribution costs should be consid- 
ered. Such concepts include three- or multi-tier architectures 
with more business logic residing on server, flexible security 
architecture, and user interface concepts that can be ported 
to a Web Browser at a later stage. 

A Netcentric architecture will usually still support devel- 
opment of client/server applications. The opposite is not 
often true since traditional client/server systems usually 
keep a substantial portion of the business logic on a fat 
chent, while Netcentric architectures still favor keeping 
most business logic at the server side. Also Netcentric 
architectures tend to be more loosely coupled than (the still 
dominant two-tier) client/server systems. 

The following sections identify the main characteristics 
associated with a Netcentric, Client Server or Host based 
technology generation. This list should in no way be con- 
sidered complete and exhaustive but is included as a starting 
point from whidi the identification process may begin. 
Network Centric Architecture Generation 

If, based upon one's client's requirements, most of the 
statements in FIG. 7 are true, one should consider an 
application based upon the Netcentric technology genera- 
tion. 

The following details the importance of each of the 
statements in FIG. 7 and should assist one in identifying the 
appropriate answer for the specific client engagement. 
Existing Architecture and Infrastructure 700 

El. Other Netcentric applications been developed and 
placed in production. 

The user community is often less resistant to accept the 
use of new technology to address changing business 
drivers if they are not completely unfamihar with the 
characteristics of the technology. If an application 
based on a Netcentric architecture has already been 
successfully piloted or deployed, acceptance of addi- 
tional systems will be eased. 

E2. The client has significant technology skills within its 
IT department. 

This is especially important if the client plans on devel- 
oping or operating the application themselves. A sig- 
nificant investment in training and changes to internal 
organizations may be necessary for successful deploy- 
ment of this type of system. The cHent must have a 
culture that supports change. Some organizations are 
very conservative and strong, making it difficult to 
deliver a successful project using new technology. 

E3. The client has multiple hardware/operating system 
configurations for their cUent machines. 

In traditional cfient/server environments, distributing an 
apphcation internally or externally for an enterprise 
requires that the application be ported, recompiled and 
tested for all specific workstation operating systems. 



us 6,636^42 B2 



27 



28 



Use of a Universal Client or web-browser may elimi- 
nate many of these problems by providing a consistent 
and familiar user interface on many different operating 
systems and hardware platforms. 
E4. The application will run on a device other than a PC. 
The momentum of the Internet is putting a lot of pressure 
on vendors of various devices to be web-enabled. 
Having the Internet infrastructure in place makes it 
more feasible for vendors to create new physical 
devices from which electronic information can be 
accessed. For example, Web televisions are gaining 
momentum. Now users can access the Internet from a 
television set. Networic Computers, thin-client devices 
that download and run applications from a centrally 
maintained server are generating a lot of interest. Also, 
users want to have access to the same information from 
multiple physical devices. For example, a user might 
want to have access to his/her e-mail from a cellular 
phone, from a Web TV or their portable PC. 
E5. The current legacy systems can scale to serve a 

potentially large new audience. 
Expanding the user community of a legacy host or client/ 
server system by including an audience which is exter- 
nal to the company can result in dramatic increases in 
system usage. The additional demand and increased 
usage placed on existing legacy systems is often diflS- 
cult to estimate or predict. Analysis must be conducted 
to ensure existing legacy systems and infrastructure can 
absorb this increase. 
Business Imperatives 702 

Bl. The client needs to reach a rjew external audience 

with this application. 
This is probably the main reason for selecting a Netcentric 
architecture. Through appropriate use of a Netcentric 
architecture it is often possible to gain exposure to new 
customers and markets. The client can often achieve 
significant competitive advantage by providing new 
services and products to its customers. Also this new 
channel makes it technically possible to develop a new 
generation of "market-of-one" products, where each 
customer can repeatedly and easy customize a product 
according to own preferences. 
B2. The client needs to reach a large or diverse internal 

audience with this application. 
Configuration management of traditional client/server 
applications, ^ch tend to be physically distributed 
across both the client and server, is a major issue for 
many corporations. The software distribution of such 
applications which are packaged as one large or a 
combination of a few large executables makes minor 
updates difficult for even a small scale user population. 
Every time an update is made, a process must be 
initiated to distribute new code to all client machines. 
The browser-centric application style offers an alterna- 
tive to this traditional problem of distributing function- 
ality to both internal and external users. 
IT Guiding Principles 704 

Gl, The client is an early adopter of new technology. 
Implementation of a Netcentric architecture can help the 
client realize a number of business benefits. However, 
the introduction of new technology into an organization 
does have inherent risks and can result in a significant 
amount of change. The client should have a culture 
which can embrace these necessary changes. 
G2. .^>plications should be developed to handle non- 
dedicated or occasional users. 
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Non-expert users need a simple to use and familiar 
interface in order to be able to use the application. As 
people grow accustomed to Web-browsers, this will be 
their preferred user-interface. The consistent interface 
provided by the Web-browsers will help reduce the 
learning curve necessary for becoming familiar with 
new applications. 
G3. Where appropriate, applications should be developed 
with multi-media capabilities for the presentation of 
data (text, sound, video, etc.). 
The ability to digitize, organize, and deliver textual, 
graphical and other information (e.g., video, audio, etc.) in 
addition to traditional data to a broader audience, enables 
new methods for people and enterprises to work together. 
Netcentric technologies (e.g., HTML documents, plug-ins, 
Java, etc.) and standardization of media information formats 
enable support for these types of complex documents and 
applications. Network bandwidth remains a performance 
issue. However advances in network technologies and com- 
pression techniques continue to make richer media-enabled 
documents and applications more feasible on the Web. 
G4. Tbe Execution, Operation and Development archi- 
tectures will be designed to support frequent releases of 
enhancements/modifications to production applica- 
tions. 

It is imperative that companies in the current market place 
be able to quickly modify their business processes in 
order to address changes in the industry. 

A Netcentric architecture simplifies frequent software 
releases for both internal and external users of the 
systems. 

Client/Server Network Generation 

If, based upon a client's requirements, most of the state- 
ments of FIG. 8 are true, one should consider an application 
based upon the Client Server technology generation. 

The following section details the importaiK^ of each of 
the statements found in FIG. 8 and should assist one in 
identifying the appropriate answer for your specific client 
engagement. 

Existing Architecture and Infrastructure 800 

El. Other Client Server applications been developed and 
placed in production and the client IT organization 
contains personnel familiar with client server architec- 
ture concepts. 

As with any new technology, there is a learning curve 
related to attaining client server development skills. 
The development process is often much more efScient 
when familiar tools and environments are used. The 
introduction of new technology can also create insta- 
bility in the operations environment. Client/server sys- 
tems still represent a new technology to many IT 
departments. 
Business Imperatives 802 

Bl. The application will be used only by an internal user 
community. 

Software distribution is a concern for traditional client 
server computing environments due to the fact that 
executable and data files need to reside on the client 
hard drive. Distribution to a user conmiunity outside of 
the client's organization is even more difficult to imple- 
ment and manage and will probably be limited to a few 
key business partners. 

B2. The application requires an advanced, dynamic, and 
integrated user interface for expert users. 

State of the art 4GL and 3GL development languages will 
support advanced user interfaces which require a sig- 
nificant degree of context management between fields 
and windows. Web-based user interfaces do not support 
such interfaces well yet. 
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B3. Session perfoimance is critical to the application or 
sub^seoond response times are required for successful 
use. 

Client server applications can provide response times 
necessary to support transaction intensive mission criti- ^ 
cal systems, ^plication logic and business data can be 
distributed between the client and server for optimal 
efficiency. Web-based interfaces still have an inherent 
overhead due to the connectionless commimication and 
constant downloading of data, formatting information 10 
and applet code. 

B4. The application needs to support off-line mobile 
users. 

Mobile computing is becoming more prevalent in the 
work place, therefore, cormectivity to a server can not 
be assumed for all user classes. A client server archi- 
tecture allows for the distribution of application logic 
and/or data between the server and client. Replication 
of data and Ic^c is usually necessary for applications ^ 
that are run on portable computers. 
IT Guiding Principles 804 

Gl. The client maintains their applications internally and 
the IT department has the necessary resources, organi- 
zations and processes to maintain a Client Server 25 
application. 

Introduction of a Client Server application to a company's 
production envirorunent can require a great deal of 
change to the Execution, Operations and Development 
architectures required to develop, run and support the 30 
production systems. Before a Client Server apphcation 
is developed, it is important that the client identify how 
a system of this type will fit within the company's 
strategic technology plan. 
Host Ardiitecture Generation 35 

If yclients business and technical requirements meet the 
following system characteristics, you should consider an 
application based upon the Host technology generation. 

The following section details the importance of each of 
the statements found in FIG. 9 and should assist you in 40 
identifying the appropriate answer for your specific client 
engagement. 

Existing Architecture and Infrastructure 900 

El . The client currently maintains and operates host based 
applications and the IT organization contains personnel 45 
famiUar with the development and operation of these 
types of applications. 
Few organizations introduce solely host based production 
systems. Usually the infrastructure for this type of 
systems already exists. New development is 
uncommon, typically existing legacy systems need to 
be extended. 

Host systems usually have a mature and stable operations 

envirormient Note that mainfi'ame expertise may be 

expensive and in high demand. 
Business Imperatives 902 

Bl. The application will only be used by a dedicated, 

expert user community ^^re a GUI is not needed. 
A dedicated work force with low turnaround, skilled in the ^ 

use of character based 3270 applications, eliminates the 

need for a GUI interface. 
B2. The application requires a high volume of repetitive 

transactions. 

The high degree of processing power provided by main- 65 
frames allows for the development of applications with 
very high performance requirements. 
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B3. The application has a requirement for significant 
batch processing. 

Mainframes are probably still the most powerful plat- 
forms for large scale batch processing. Mature tools 
exist for scheduling, recovery/restart, sorting, merging, 
and moving large sets of data. 

B4. End users can maintain a physical cormection to the 
host at all times. 

Physical connection to the host is required for use of the 
applications. Methods of mobile computing with dis- 
tribution of data or business logic is not possible. 

B5. The application will need to support a large number 
of users (>1000). 

The processing power of today's mainframe lends itself 
well to the development of large scale, mission critical 
applications with a large user base. 
IP Guiding Principles 904 

Gl. The Client has the resources, organizations and 
processes necessary for the development and operation 
of a Host based application. 

Before a Host based application is developed, it is impor- 
tant that the client identify how a system of this type 
will fit within the company's strategic technology plan. 

G2. Reliance upon a single vendor (IBM) for technology 
solutions is acceptable. 

Selection of a host based architecture inherently locks the 
client into dependence upon one vendor for its tech- 
nology solutions. While IBM is a reputable, stable 
company it may be important to ensure that the client's 
long term business strategy will be supported by IBM's 
technology vision and direction. 

G3. Centralized application and data is an acceptable 
strategy. 

A pure host based architecture eliminates the possibility 
of distributing data or business logic to the client. This 
removes some of the application performance benefits 
which can be seen by a distribution strategy, however, 
centralized access to the business logic and business 
data can improve operational stability and lower costs. 
A current trend is to transform mainframe based legacy 
systems into data- and application servers in a multi- 
tiered client/server or Netcentric architecture. 
Overview of the Frameworks 

One may ask: what frameworks one should use? This 
portion of the specification should help one understand: 
when the various frameworks in SAF can be useful 
how the frameworks are related 
Frameworks Related to Delivery Vehicles 

Most of the frameworks in SAF address various aspects of 
Delivery Vehicle architectures. 

SAF provides access to the user's thought leadership and 
architecture frameworks for Execution, Development and 
Operations environments. Very briefly, SAF covers: 
The Core Execution Architecture frameworks for the 
different architecture generations (Host, Client/Server 
and Netcentric). Most users will primarily use the 
Netcentric framework. 
The Execution Architecture Extensions. This is a collec- 
tion of the most common delivery vehicles that are built 
for clients. These frameworks extend the core fire- 
works with services specific for a particular delivery 
vehicle. 

The Development Architecture Framework. Should help 
one establish and operate a high-quality development 
envirormient. 
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The Operations Architecture Framework. Should help one 
establish and operate a high-quality operations envi- 
ronment. 

To learn more about what Delivery Vehicles are, see the 
Delivery Vehicle Overview section. This page explains 
the relationships between Architecture Generations, 
y^plication Styles and Environments. 
Framework Extensions and other Frameworks 

The remaining frameworks in SAF are ^cial purpose 
frameworks that may not directly fit into the current Deliv- 
ery Vehicle definition. 

They may be extensions to the delivery vehicle frame- 
works such as Call Center, Mobile, eComnnerce Application 
Framework, Middleware or Component Technologies. 
Framework Recommendations 

The frameworks in SAF address different a^cts and 
areas of technology and application architecture. No single 
framework may cover this scope. Depending on the phase of 
one's project and the type of applications one's project will 
deliver, one may need to use different specialized frame- 
works. 

Most implementations today may begin by considering 
the Netcentric Execution framework, then adding extensions 
for the delivery vehicles or specific technologies that your 
project will use. Keep in miisd, however, the Development 
and Operations frameworks. Also, remember that some 
architectures will need to be built on multiple frameworks, 
most likely involving the Integration framework to bridge 
between them. 

This section lists all the frameworks currently available in 
SAF, indicates when they may be useful, and how it relates 
to other frameworks: 
Netcentric 

When is it usefiil? 

This framework constitutes the core of a modem netcen- 
tric and client/server execution ardiitecture. It will help one 
plan and design one's architecture by understanding what 
components a typical netcentric architecture should consist 
of. 

Netcentric Ardiitetcure Framework 
Framework Overview 
Introduction 

The Netcentric Architecture Framework identifies those 
run-time services required when an application executes in 
a Netcentric environment. As shown in FIG. 10, the services 
can be broken down into logical areas: Presentation Services 
1000, Information Services 10024^004, Communication Ser- 
vices 1006J.008, Communication Fabric Services 1010, 
Transaction Services 10124014, Environment Services 
10164018, Base Services 1020 and Business Logic 1022, 
1024. This framework is an evolution of the Client Server 
New Age Systems Framework and is useful for technical 
architects involved in the selection, development and 
deployment of technical architectures in a Netcentric envi- 
ronment. More discussion of each of these logical areas is 
provided below. See also FIGS. 11 and 12, which are 
detailed diagrams of the components of the Netcentric 
Architecture Framework found in FIG. 10. 
Netcentric Computing Top 10 Points 

Netcentric computing represents an evolution — it builds 
on and extends, rather than replaces, client/server. 

Netcentric computing has a greater impact on the entire 
business enterprise, hence greater opportunity and risk. 

Definitions of Netcentric may vary. One is about reach 
and content. 

Netcentric is not just electronic commerce; it can impact 
enterprises internally as well. 
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You can begin identifying Netcentric opportimities for 
clients today. 

There are three basic types of Netcentric applications: 

advertise; inquiry; and fiilly interactive. 
One can underestimate the impact of Netcentric on infra- 
structure requirements. 
Build today's client/server engagements with flexibility to 
extend to Netcentric. 
Netcentric Computing Definition 

Netcentric Computing also called Netcentric 
Architecture, Netcentric Technology, etc. is an emerging 
architecture style which expands the reach of computing 
both within and outside the enterprise. Netcentric enables 
sharing of data and content between individuals and appli- 
cations. These applications provide capabilities to publish, 
interact or transact. Netcentric represents an evolution of 
Client/Server which may utilize internet technologies to 
connect employees, customers, and business partners. 
Client/Server vs. Netcentric Computing (NCC) 

NCC is a new style of computing that expands on the 
technological base already provided by traditional client/ 
server systems. Many of the traditional chent/server design 
concepts and considerations still apply to NCC. 

The important differences between client/server systems 
and NCC systems are: 
The way in which the application logic is distributed to 
clients is different in NCC and traditional client/server 
systems. In NCC systems, application logic can be 
packaged into components and distributed from a 
server machine to a client machine over a network. In 
traditional client/server systems, the application logic is 
split between the client and the server on a permanent 
basis; there is no dynamic distribution of apphcation 
logic. 

The number of tiers in NCC and traditional client/server 
systems is different. NCC extends the traditional two- 
tier client/server architecture to a n-tier architecture. 

The client in NCC systems is different from a client in 
traditional client/server systems. The client in a NCC 
system is a standardized universal one; a NCC appli- 
cation can execute within a chent that can run on 
multiple operating systems and hardware platforms. In 
traditional client/server systems, the client is custom- 
made for a specific operating system and hardware 
platform. 

The way in which NCC and traditional client/server 
systems can be extended and adapted is different. 
Components enable NCC systems to be adaptable to a 
variety of distribution styles, from a "thin client" to a 
"fat client". In comparison, traditional client/server 
systems, once designed and built, cannot be adapted for 
use on more than one computing style. 
Tiers 

Similarly to traditional client/server architectures, Net- 
centric architectures support a style of computing where 
processes on different machines communicate using mes- 
sages. In this style, "client" processes delegate business 
fimctions or other tasks (such as data manipulation logic) to 
one or more server processes. Server processes respond to 
messages from clients. 

Business logic can reside on both chent and server. 
Clients are typically PCs or Workstations with a graphical 
user interface ruiming in a Web browser. Servers are u^ally 
implemented on UNIX, NT or mainframe machines. 

A key design decision for a client/server system is 
whether it ^ould be two-tiered or muld-tiered and how 
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business logic is distributed across the tiers. In Netoentric 
architectures there is a tendency to move more business 
logic to the server tiers, although "fatter'' cHents are becom- 
ing more popular with newer technologies such as Java and 
ActiveX. 

Two-Tiered Architectures 

Two-tiered architecture describes a distributed application 
architecture in which business applications are split into 
front-ends (clients) and back-ends (servers). Such a model of 
computing began to surface in the late 1980s and is the 
prominent configuration in use today by companies which 
have attempted to migrate to client/server based computing. 
Advantages 

At a minimum, a two-tiered client/server architecture 
assumes that an application's presentation logic resides on 
the client and its data management logic resides on the 
server. This style of computing became attractive to early 
adopters of client/server because it clearly addresses the 
inadequacies of a character-based interface. That is, it allows 
PC-based chents to introduce a graphical user interface 
(GUI) into the application environment. 

Allows rapid development "out-of-the-box" 

Decreased communication overhead because of a direct 
coimection (for a small number of users) 

Allows the distribution of the program's logic 
(application, presentation, data management) 
Limitations of Two-Tiered Architecture 

The use of two-tier tools has resulted in a def acto "client- 
heavy" or "fat-client" two-tiered model where the presen- 
tation and application logic resides on the client and data 
management resides on the server. In fact, the use of these 
tools "out-of-the-box" assumes the adoption of such a 
model. Unfortunately, such an architectural model falls short 
of addressing many important issues required of an 
enterprise-wide information architecture. This model of 
computing was actually developed for less-demanding PC 
enviromnents where the database was simply a tool for 
decision support. 
Limitations 

Limited/cost prohibitive Scalability 

Limited availabihty 

Limited reliability 

Security Deficiencies 

Network/Database bottlenecks 

Low implementation flexibility 

Limited Asynchronous processing 
Three-Tiered or Multi-Tiered Architectures 

Three-tiered architecture describes a distributed applica- 
tion architecture in which business applications are sepa- 
rated into three logical components: presentation and 
control, application logic, and data management. These 
logical components are "clean layered" such that each rans 
on a different machine or platform, and communicates with 
the other components via a network. 

A three-tiered architecture is often enhanced by the inte- 
gration of distributed transaction processing middleware. 
This model of computing is often termed the "enhanced" 
client/server model. Most Netcentric architectures use a 
three- or four tiered approach with a web server and poten- 
tially a separate appUcation server layer. 

In the enhanced client/server model, all presentation and 
control logic resides on the client, all application logic 
resides on multiple back-end application servers, and all 
data management logic resides on multiple back-end data- 
base servers. 
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Advantages 

In contrast to mainframe and two-tiered client/server 
computing models, the principle advantage with a three- 
tiered enhanced client/server architecture is that it provides 
the benefits of a GUI application, but also provides a level 
of integrity and reliability found in mainframe centralized 
computing. That is, it will evolve to serve high-volume, 
high-integrity, and high-availability environments. 

Location and implementation transparency — The use of a 
transaction manager such as Tuxedo allows for service 
location independence. 
Distribution of Ic^c to optimal resource — Since the 
application and database functions reside on their own 
physical devices, each can be optimally tuned for the 
work they perform. 

Database scaleable on throughput — ^In the enhanced 
three-tiered client/server model, cUent appUcations no 
longer connect directly to database servers. Instead, 
only application servers connect to the database serv- 
ers. 

Security over service resources — With the application 
logic residing on back-end application servers, security 
over the applications is made possible at various levels. 

Redundancy and resihency of services — A major disad- 
vantage prominent in other models of computing is 
"single point of failure. 

Optimization of personnel resources — Developers can be 
utilized for specific talents in each tier. 

Allows for asynchronous and standardized messaging — 
The enhanced cHent/server model is really a superset of 
the RPC-based function shipping model which pro- 
vides features such as asynchronous^ event-driven pro- 
gramming. 

Administration, configuration, prioritization — The use of 
a transaction manager enables servers to be added, 
removed, or restarted dynamically. This allows for very 
robuist, scaleable, and flexible applications. 
Disadvantages 

Three-tier architectures are highly flexible. This flexibility 
comes with the cost of being more complex to implement. 
Limitations 

Additional tool (middleware) selection 
Longer implementation times 

Greater development costs associated with additional tier 
More complex planning 
Additional Skills 
Extra Hardware 

Greater complexity for maintenance, configuration man- 
agement 
Presentation 1000 

Presentadon Services enable an application to manage the 
himian-computer interface. This includes capturing user 
actions and generating resulting events, presenting data to 
the user, and assisting in the management of the dialog flow 
of processing. FIG. 13 illustrates several components of the 
Presentation area of the Netcentric Architecture Framework. 

Exemplary products that may be used to enable this 
component include Msual Basic; PowerBuilder; C++; Win- 
dows 3.X/NT/95; X-Wndows/Motift Visual C++; Borland 
Delphi; AC FOUNDATIGN for FCP. 

The products listed as candidates for ^dfic components 
here and below ^ould be used with care. These examples do 
not provide an all-inclusive list, nor do they nec^sarily 
represent the current market leaders. They are there to 
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provide an example of products that may enable the com- Form 1304 

poneot services. Form Services enable applications to use fields to display 

Window System 1300 and collect data. A field may be a traditional 3270-style field 

Typically part of the operating system, the Window Sys- used to display or input textual data, or it may be a graphical 
tem Services provide the base functionality for creating and 5 field such as a check box, a list box or an image. Form 

managing a graphical user interface (GUI) — detecting user Services provide support fon 

actions, managing windows on the display, and displaying Display— support the display of various data types (e.g., 

information in windows. text, numeric, date, etc.) in various formats (e.g., American/ 

Implementation Considerations European date, double-byte characters, icons, etc.) 

Endowing systems expose their functionaUty to appU- lO input/Validation-^nable applications to collect informa- 

cation programs through a set of appUcation programming tion fi-om the user, edit it according to the display options, 

interfaces (APIs). For the Microsoft windowing platform, and perform basic validation such as range or format checks, 

this API is called Win32. The Win32 API is a documented nj™™ c,.™^ * *u i* *• * 

* r r-ftrt ^ £. *t. * 11 J 1 * Mappmg Support — emnmate the need for appucations to 

set of over 500 C functions that allow developers to access . , j . • j • ^ 
*i- XL *• !•* r*u • ^ • * 11 • .r- conmiumcate directly with the wmdowmg system: rather, 

thefimctionahtyof the windowmg system as well as vanous 15 i- j- i j * . ^ « 

** * c ^ xiTu i * ' -ui * apphcations retrieve or display data by automatically copy- 
other operatmg system nmctions. While it is possible for • \u * ♦ p * j » c i ^ * j_ i r *: 

J 1 * ^ 1*1 ti*u XYT' -y'y ATiw •* • 1 * mg the contents of a wmdow's fields to a copybook structure 

developers to directly call the Wm32API or its eqmvalent on . c? • t i_ ^\ . . t_ 

^ • 1 -1 * w • ^ memoiy. These Services may also be used to automate the 

otherp atformsusmgaC lanp.age«mpU^^^ meigiDg of application data wiih pre-defined electronic form 
application development is done usmg higher level devel- 

opment languages such as \%ual Basic or PowerBuilder 20 J^ * . 

which make the lower level calls to the operating systems on Field InteracUon Management-coordmate activity 
behalf of the developer. ^'^^^^ ^^^^^ i° ^ window by managing field inter- 
Exemplary products that may be used to enable this dependencies and invoking application logic based on the 
component include Microsoft Windows; Windows 95; Wm- ^^^^ ^""^ example, the Field 
dows NT; Macintosh OS; Program Manager for OS/2; 25 Interaction Manner may disable the "OK" button until aU 
X-\Wndows/Motif' JavaOS. reqmred mput fields contam vahd data. These services 
Desktop Manger 502 significantly reduce the application logic complexity inher- 

Desktop Manager Services implement the dedrtop meta- ^ interactive windowed interface, 

phor. The desktop metaphor as the name suggests is a style Implementation Considerations 

of user interface that tries to emulate the idea of a physical 30 In traditional client/server applications, Fomis are win- 
desktop allowing you to place documents on the desktop, dows that contain widgets (text fields, combo-boxes, etc.) 
launch applications by clicking on a graphical icon, or and business logic. Form development tools such as Msual 
discard files by dragging them onto a picture of a waste Basic, PowerBuilder, etc. allow the Forai designer to specify 
basket. Most Window Systems contain elementary Desktop page layout, entry fields, business logic, and routing of 
Manager functionality (e.g., the Wndows 95 desktop), but 35 forms. From a developers perspective, these products typi- 
often more user firiendly or functional De^rtop Manager cally expose Form and control handling fiinctionality as a set 
Services are required. of proprietary or product specific APIs. 
Microsoft Windows 95 Task Bar; Norton Navigator, Xerox In addition to the traditional tools (e.g., \%ual C++, 
Tabworks; Starfish Software Dashboard Visual Basic, PowerBuilder), Netcentric technologies have 
Product Considerations 40 introduced new tools that can be used to develop Forms. For 
Exemplary products that may be used to enable this example, a developer can use Symantec ^sual Caf6 to 
component include: create a Java application that will execute directly on the 
Microsoft Wmdows 95 task bar— provides a launch bar desktop without any interaction with a browser, 
which allows users to access recently used documents. Today most Netcentric applications are Web based and are 
launch applications, or switch between active applica- launched from the Web browser. Additionally, one is now 
fions. The Wndows 95 desktop and launch bar are beginning to see other types of Netcentric solutions. For 
programmable allowing users to extend and customize example, PointCast is a Netcentric application located on the 
the desktop manager for their specific application. For users machine; it relies on the Internet to deliver stock 
example, the desktop can be exteiKled with icons or prices, news headings, sports updates, etc. to the user. 
Start Menu options for creating a new customer However, it is not launched fi-om the Web browser — it is its 
account or finding an order. own application. In the future there will be more Netcentric 
Norton Navigator— provides multiple virmal desktops, applications that use this approach for delivering infonna- 
enhanced file management including direct FTP 

connectivity, long file name support for some 16-bit Product Considerations 

applications, file un-erase, and other features; targeted What level of technical support, documentation, and 

at users who often interact with the Wndows 95 training is required to ensure the productivity of developers? 

desktop. The extent of support (on-site, phone, bulletin board, 

Xerox Tabworks — presents the user with a notebook world-wide, etc.), quality of documentation, and availability 

metaphor for application and document access; allows and location of education/training should be considered, 

creation of tabbed sections which contain related files What fiinctions are required in the control set? 

(e.g., Winston Account or New Product Launch) for At the minimum a tool should support basic widgets (push 

easier access. buttons, list boxes, etc.), window styles, (multi-window. 

Starfish Software Dashboard — a desktop utihty designed multi-document, paned-window), and menu styles, along 
to simplify apphcation and system management; pro- 65 with validation and inter-application communication. Con- 

vides quick launch buttons, system resource gauge, sideration should also be given as to the extensibility of the 

drag-and-<irop printing and faxing, calendar, etc. toolset via add-ons and third party products. 
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Can the tool be used for both prototyping and GUI Does the tool support programming extensions to 

design? Dynamic Link Libraries? 

The ability to use a single tool for both prototyping and What are the debugging capabilities of the tool? 

GUI design will reduce the development learning curve. Is the tool scalable? 

One should also consider how well the tool integrates will all 5 The tool should be scalable to support growth in apph- 

other development tools. cation size, users, and developers. 

What platform(s) are supported? Exemplary products that may be used to implement this 

The platform(s) that must be supported, i.e., MS-DOS, component include JetFonns JetFonn Design; Lotus Forms; 

Wmdows, IBM OS/2, UNIX, or U^aX Motit is an impor- visual Basic. 

tant consideration, as are any hardware restrictions. , t .1- • -j . 1 - 

What type of learning cuiVe is associated with the tool? ^° "^^^^^^"^ ^^^f Design-provides tools to design, fill. 

Developers using the product should be able to become P""^ f ^ '"^^Se electtonic forms, helping orga- 

productive quickly. Factors which reduce the learning curve mzations reduce coste and mcrease efficiency by auto- 

iochide an easy to learn and intuitive interface, thorough and matmg processmg of forms across local and wide area 

clear documentation, and on-Une help. networks as well as the Internet. Lotus Formsr-Lotus 

If the tool is also going to be used for application Development Corporations electronic forms software 

development, how well does the tool perform during pro- provides tools to design, route and track forms to 

duction? automate business processes for the workgroup or the 

Computational, network, data retrieval, and display extended enterprise. Lotus Forms is designed to run 

speeds differ for products. Factors to consider are whether with Lotus Kotes or as a standalone appUcation. It is 

the application will consist of heavy data entry, transaction 20 comprised of two parts: Forms Designer, an 

processing, or a large user base. application-development version, and Forms Filler, a 

How much does the tool cost? runtime version for users. Visuai Basic — a develop- 

Product components, maintenance agreements, upgrades, ment tool that provides a comprehensive development 

run-time licenses, and add-on packages should be consid- environment for building complex applications, 

ercd- 25 User Navigation 1306 

Does the product integrate with other tools and/or support User Navigation Services provide a user with a way to 

other tools in the development and execution environments? access or navigate between functions within or across appli- 

It is important to determine how well the product inte- cations. Historically, this has been the role of a text-based 

grates with other (tesign and development tools, presentation menuing system that provides a list of applications or 

services (graphics, multi-media, etc.), data access services 30 activities for the user to choose from, 

(databases and database API h'braries), distribution services Client/server technologies introduced new navigation 

(distributed TP monitor), transmission services (SNA, metaphors. A method for allowing a user to navigate within 

HLLAPI, etc.), data dictionary, desktop apphcations, and an application is to list available functions or information by 

programming languages for call-out/call-in. Additional con- means of a menu bar with associated pull-down menus or 

sideration should be given to add-on and third-party 35 context-sensitive pop-up menus. This method conserves 

products/enhancements such as ^dalized widgets, report sCTeen real-estate by hiding functions and options within 

writers and case tools. menus, but for this very reason can be more difficult for first 

the tool be used with a large development team? time or infrequent users. This point is important when 

If the development team is more than 5 people, a tool implementing electronic commerce solutions where the tar- 
should provide support for multiple developers. This support 40 get customer may use the application only once or very 
includes features such as object check-in/check-out, a cen- infrequently (e.g., purchasing auto insurance), 
tral design repository for the storage of application objects Additionally, client/server development tools such as 
and user interface definitions, and version control. \%ual Basic and PowerBuilder do not provide specific 
Additionally, the development team should be able to services for graphical navigation, but the effect can be 
cleanly divide the application(s) into pieces which can be 45 recreated by selecting (i.e., clicking on) graphical controls, 
worked on by multiple people. such as picture controls or iconic push-buttons, progranuned 

What protocols are used to communicated with the data- to launch a particular window. 

A major advantage of the graphical user interface is the 

Important considerations include the supported databases fact that it allows multiple windows to be open at one time, 

and protocols used to communicated with the databases. The 50 Implementation Considerations 

tool must support the selected database. Additionally, if the Is there a need to manage multiple instances of a window 

database selection may change, it is important that the tool object? 

have the ability to support other databases with minimal Windows Interaction Manager provides the application 
impact on the application development. Native database with facilities to open multiple instances of the same win- 
interfaces tend to have better performance than open stan- 55 dow. This component provides an option parameter that will 
dards such as ODBC. let the application developers enable or disable the ability to 

Will the design tool be used for programming of client open the same window with the same key data (that is, a 

applications? What programming language is supported? duplicate instance). 

If the design tool is used for programming, there are Do you need to pass messages between win^ws? 

several features of a tool which must be considered. These 60 Windows Interaction Manager provides the facility to 

features can have an impact on the productivity of pass messages between windows within one application, 

programmers, performance of the applications, skill sets This allows one window to trigger an event/action on 

required, and other tools required for development. These another related window. 

features include: Do multiple applications need to pass messages between 

What programming language is supported? Is the pro- 65 each other? 

gramming language interpretive or compiled? Is it Windows Interaction Manager provides the facility to 

object oriented or structured procedural language? pass messages between windows from different applications 
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residing on the same mactuDe. This allows one window to and easy Web publishing. As a result, they developed 

trigger an event/action on an related window when certain HyperText Markup Language (HTML), a relatively simple 

actions (user or environment) occur. application of SGML. This simplicity has contributed to the 

If information needs to be shared between applications on exponential growth of the Web over the last few years, 

different machines, Window Interaction Management can- 5 ™^ files arc written m plam text and can be created using 

not be used. This type of data sharing requires a special ^"^Jf ^ ^^-^ ^°^"fo "^^^ ^^^^ authoring 
. ^ ,1 J ^ • ^Yv . software (such as Microsoft's FrontPage or Sausage Soft- 
architecture component called CommunicaUon, which is HotDog) to the anemic Notepad utility included with 
more network onenlated. Microsoft's Wmdows operating system. 

Is there a need for object registration/de-registration? As with many languages, HTML is in a state of constant 

Wndows Interaction management allows the application lo evolution. The World Wide Web Consortium W3C oversees 

to control and manage the opening and closing of multiple new extensions of HTML developed by both software 

windows by — maintaining the parent-child relationship, companies (such as Microsoft and Netscape 

controlling multiple instances of similar windows, maintain- Communications) and individual Web page authors and 

ing key data-window relationship. This allows the user to ensures that each new specification is fuUy-oompatible with 

work in a controlled and, well managed, environment. is previous ones. Basic features supported by HTML include 

Web Browser 1308 headings, fists, paragraphs, tables, electronic forms, in-fine 

Web Browser Services allow users to view and interact images (images next to text), and hypertext links. Enhance- 

with applications and documents made up of varying data original HTML 1.0 specification include 

types, such as text, graphics, and audio. These services also fanners, the applet tag to support Java, image maps, and text 

provide support for navigation within and across documents 20 ^^iSL^ ^^^^ , . . . ^ 

no matter where they located, through the use of links S^^^^h.^'^JSTT^ r^nT,^^ "^"^ * ° 

embeddedintothed^entcontent-WrBrowserServices fi^fSTLS^^HfeflE^^ 

.... 1 • I . . L . 1 1 . iication builds upon earlier iterations of HTML by enabuns 

retam the link connection, i.e., document phy^ location, ^eb authors to include advanced forms, in-Hne frames, and 

and made the complexiUes of that connection from the user. enhanced tables in Web pages. HTML 4.0 also aUows 

Web Browser services can be fiirther subdivided into: 25 authors to pubUsh pages in any language, and to better 

Browser Extension, Form, and User Navigation. manage differences in language, text direction, and character 

Parlez-Vous Internet? encoding. 
The Elements of Web Style Perhaps most significantly, HTML 4.0 increases authors' 
Language philosopher Benjamin Whorf once said, "We control over how pages are organized by adding support for 
dissect nature along lines laid down by our native language. 30 Cascading Style Sheets CSS Style sheets contain directions 
Language is not simply a reporting device for experience, for how and where layout elements such as margins, fonts, 
but a defining framework for it." This notion is especially headers, and links arc displayed in Web pages. Wth CSS, 
true when appfied to the World V/idG Web. The evolution of authors can use programming scripts and c^jects to apply 
the Web from a rigid, text-centric village to an elastic, multiple style sheets to Web pages to create dynamic con- 
multimedia-rich universe has been driven by modifications 35 *^an also be used to centralize control of layout 
to the languages behind it. The Internet is at a crucial point attributes for multiple pages within a Web site, thus avoiding 
in its development as a number of enhancements for extend- tedious process of changing each page individuaUy. 
ing Web technology come under scrutiny by Internet stan- HTNtt-: Dyn-o-nute! 

dards groups. These enhancements wiU ultimately push the . ™^^^ simphoty soon began to fimit authors who 

Web into tiierealmsofdistributed document processing and 40 tt^^^ "^'''"'^^ S^^Tn^r f^^ "^^"^ 

interactive multimedia. J^^r.fl^f^n\^ k ^™^^^JP 

cr-MT • tu Ti * * sion of HTML, DHTML allows Web pages to fimction more 

AUh^ i°*K w w K . * ^ .1 .u ^ interactive CD-ROMs by responding to user-generated 

Although the World Wide Web was not created until the events. DHTML aUows Web pagrobjecSto be manipulated 

early 1990s, the language behind it dates back to the genesis after they have been loaded into a browser. Tbis enables 

of the Internet m the 19605. Scientists at IBM were working 45 users to shun plug-ins and Java applets and avoid 

on a Generafized Markup Language (GML) for describing, bandwidth-consuming return trips to the server. For 

formatting, and sharing electronic documents. Markup example, tables can expand or headers can scurry across the 

refers to the practice in traditional publishing of annotating page based on a user's mouse movements, 

manuscripts with layout instructions for the typesetters. Unfortunately, the tremendous potential offered by 

In 1986, the International Standards Organization (ISO) 50 DHTML is marred by incompatible standards. At the heart 

adopted a version of that early GML called Standard Gen- of the DHTML debate is a specification called the Document 

eralized Markup Language (SGML). SGML is a large and Object Model DOM. The DOM categorizes Web page 

highly-sophisticated system for tagging documents to ensure elements — including text, images, and linkfrr-^ objects and 

that their appearance will remain tiie same regardless of the specifies the attributes that are associated with each object, 

type of platform used to view them. Designers use SGML to 55 ^? makes Web document objects accessible to 

create Document Type Definitions (DTDs), which detail scnpting languages such as JavaScript and MsualBasic 

how tags (also known as format codes) are defined and (VBScnpt), which can be used to change the 

interpreted within specified documents. These tags can be locaUon, and even the content of those objects 

ll^nt'fte'^TH ^^^f ^aTT^ ' "^T' '°Micn)soft'sInternetExplorer4.0supportsaW3C«Woik- 

TdLcrill^f.^^^^^^^ ingDraft-DOMspedficationthatusesTeCSSstandardfor 

and highly-str^tureddocmnents that are subject to frequent j ^ control and Web document object manipulation. In 

revisions, such ^ dicUonanes, mdexes, computer manuals, contrast, Netscape's implementation of DHTML in Com- 

^i^^^'^^^iJ^^r °^ municator 4.0 uses a proprietary "Dynamic Layers" tag, 

HTML: SGML for Dummies? which assigns muhiple layers to a page within which objects 
While creating the World Wide Web in the early 1990s, 65 are manipulated. As a result, Web pages authored using 

scientists at CERN discovered that in i^ite of its power and either version of DHTML may not be viewed property using 

versatility, SGML's sophistication did not allow for quick the other's browser. XML: X marks the spot 
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HTML 4.0 and Dynamic HTML have given Web authors match their movements and give the impression that they are 

more control over the ways in which a Web page is dis- moving through real space. The new VRML 2.0 ^cifica- 

played. But they have done little to address a growing tion finalized in August 1996 intensifies the immersive 

problem in the developer community: how to access and experience of VR worlds on the Web by enabling users to 

manage data in Web documents so as to gain more control 5 interact both with each other and with their surrounding^, 

over document structure. To this end, leading Internet devel- Other new features supported by VRML 2.0 include richer 

opers devised Extensible Markup Language (XML), a geometry description, background textures, sound and 

watered-down version of SGML that reduces its complexity video, multilingual text, Java applets, and scripting using 

while maintaining its flexibility. Like SGML, XML is a VBScript and JavaScript. VRML will become a significant 

meta-language that allows authors to create their own cus- lo technology in creating next-generation Internet application 

tomized tags to identify different types of data on their Web as the language continues to mature and its availability 

pages. In addition to improving document structure, these increases. 

tags will make it possible to more effectively index and The Future: Give us a Big SMIL 

search for information in databases and on the Web. The Web has come a long way since the codification of 

XML documents consist of two parts. The first is the 15 HTML 1.0. It has moved from simple text-based documents 

document itself, whidi contains XML tags for identifying that included headings, buUeted lists, and hyperlinks to 

data elements and resembles an HTML document. The dynamic pages that support rich graphic images and virtual 

second part is a DTD that defines the document structure by reality. So what next for the Web? The answer resides in a 

explaining what the tags mean and how they should be Synchronized Multimedia Integration Language (SMIL), a 

interpreted. In order to view XML documents, Web brows- 20 new markup language being developed by the W3C. SMIL 

ers and seardi engines will need special XML processors wiU allow Web authors to deliver television-like content 

called "parsers." Currently, Microsoft's Internet Explorer over the Web using less bandwidth and a simple text editor, 

4.0 contains two XML parsers: a high-performance parser rather than intricate scripting. 

written in C++ and another one written in Java. SMIL is based on XML and does not represent a specific 

A number of vendors plan to use XML as the underlying 25 media format. Instead, SMIL defines the tags that link 

language for new Web standards and applications. Microsoft different media types together. The language enables Web 

uses XML for its Channel Definition Format, a Web-based authors to sort multimedia content into separate audio, 

"push" content delivery system included in Internet Explorer video, text, and image files and streams which are sent to a 

4.0. Netscape will use XML in its Meta Content Framework user's browser. The SMII^ tags then specify the "schedule" 

to describe and store metadata^ or collections of information, 30 for displaying those components by determining whether 

in forthcoming versions of Communicator. XML is currently they should be played together or sequentially. This enables 

playing an important role the realm of electronic commerce elaborate multimedia presentations to be created out of 

via the Open Financial Exchange, an application developed smaller, less bandwidth-consuming components, 

by Microsoft, Intuit, and CheckFree for conducting elec- Implementation Considerations 

tronic financial transactions. Similarly, HL7, a healthcare 35 Many features such as graphics, frames, etc. supported by 
information systems standards organization, is uising XML Web Browsers today were not available in initial releases, 
to support electronic data interchange EDI of clinical. Furthermore, with every new release the functionality sup- 
financial, and administrative information (http:// ported by Web Browsers keeps growing at a remarkable 
www.mcis.duke.edu/standards/HL7/sigs/sgml/index.html). pace. 

Meet Cousin VRML 40 Much of the appeal of Web Browsers is the ability to 

In 1994, a number of Internet thought leaders, including provide a universal client that will offer users a consistent 

Tim Bemers-Lee — the "father" of the Web — met to deter- and familiar user interface from which many types of 

mine how they could bring the hot, new technology known applications can be executed and many types of documents 

as virtual reality VR to the Web. VR refers to the use of can be viewed, on many types of operating systems and 

computers to create artificial and navigable 3-D worlds 45 machines, as weU as independent of where these applica- 

where users can create and manipulate virtual objects in real tions and documents reside. 

time. This led to the creation of \^rtual Reality Modeling Web Browsers employ standard protocols such as Hyper- 
Language (VRML-Pronounced "ver-mul"). VRML is tech- text Transfer Protocol (HTTP) and File Transfer Protocol 
nically not a markup language because it uses graphical (FTP) to provide seamless access to documents across 
rather than text-based file formats. 50 machine and network boundaries. 

In order to create 3-D worlds and objects with VRML, The distinction between the desktop and the Web Browser 

usersneeda VRML editor such as Silicon Graphics' Cosmo narrowed with the release of Microsoft IE 4.0, whidi 

Worlds (http://cosino.sgi,com/products/studio/worlds). To integrated Web browsing into the desktop, and gave a user 

view VRML content, users need either a VRML browser or the ability to view directories as though they were Web 

a VRML plug-in for standard HTML browsers. Leading 55 pages. Web Browser, as a distinct entity, may even fade 

VRML plug-ins include Cosmo Player from Silicon Graph- away with time. 

ics (http://vrml.sgi.com/oosmoplayer). Liquid Reality from Exemplary products that may be used to implement this 

Microsoft's DimensionX subsidiary (http:// component includes Netscape Navigator; Netscape Commu- 

www.microsoft.com/dimensionx), OZ Virtual from OZ nicator; Microsoft Internet Explorer; Netscape Livel^lre; 

Interactive (http://www.oz.com/ov/main_bot.html), and 60 Netscape LiveWre Pro; Symantec Msual Cafe; Microsoft 

World\1ew from Intervista (http://www.intervista.com/ Front Page; Microsoft Visual J++; IBM \^ualAge. 

productsAvorldview/index.html), These plug-ins can typi- Execution Products 

cally be downloaded for free from the Web. Netscape Navigator or Communicator — one of the origt- 

VRML is capable of di^laying static and animated nal Web Browsers, Navigator currently has the largest 

objects and supports hyperlinks to multimedia formats such 65 market share of the installed browser market and strong 

as audio clips, video files, and graphical images. As users developer support. Cbmmunicator is the newest version 

maneuver through VRML worlds, the landscape shifts to with add-on collaborative fimctionality. 
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Microsoft Internet Explorer (IE) — a Web Browser that is 
tightly integrated with Windows and supports the major 
features of the Netscape Navigator as well as 
Microsoft's own ActiveX technologies. 
Development Products 

Web Browsers require new or at least revised develop- 
ment tools for woridng with new languages and standards 
such as HTML, ActiveX and Java. Many browser content 
development tools arc available. The following arc several 
representative products: 

Netscape Live^^e and LiveWre Pro — visual tool suite 
designed for building and managing complex, dynamic Web 
sites and creating live online applications. 

Symantec \^ual Caf6 — the first complete Rapid AppM- 
cation Development (RAD) environment for Java; it allows 
developers to assemble complete Java applets and applica- 
tions firom a library of standard and third party objects. 
Visual Caf6 also provides an extensive set of text based 
development tools. 

Microsoft FrontPage — ^Web site management tool that 
supports web page creation, web site creation, page and 
link management and site administration. 
Microsoft \^al J+-i — a product similar to Visual C++, 
VJ++ allows the construction of Java and ActiveX 
applications through an integrated graphical develop- 
ment environment. 
IBM MsualAge for Java — ^a product similar to VisualAge 
for Smalltalk, VJ++ allows the construction of Java 
applications through an integrated graphical develop- 
ment environment. It supports JavaBeans. Used by 30 
Eagle team for the Eagle JavaBeans reference applica- 
tion. 

Browser Extension 1310 

Browser Extension Services provide support for execut- 
ing different types of applications from within a Browser. 
These applications provide functionality that extend 
Browser capabilities. The key Browser Extensions arc: 

Plug-in — a term coined by Netscape, a plug-in is a 
software program that is specifically written to be executed 
within a browser for the purpose of providing additional 
functionality that is not natively supported by the browser, 
such as viewing and playing unique data or media types. 
Typically, to use a phig-in, a user is required to download 
and install the Plug-in on his/her client machine. Once the 
Plug-in is installed it is integrated into the Web browser. The 
next time a browser opens a Web page that requires that 
Plug-in to view a q>ecific data format, the browser initiates 
the execution of the Phig-in. Until recently Plug-ins were 
only accessible from the Netscape browser. Now, other 
browsers such as Microsoft's Internet Explorer are begin- 
ning to support Plug-in technology as well. Also, Plug-ins 
written for one browser will generally need to be modified 
to work with other browsers. Plug-ins arc also operating 
system dependent. Therefore, separate versions of a Phig-in 
may be required to support Wndows, Macintosh, and Unix 
platforms. 

Helper .^)plication/\^ewer — is a software program that is 
launched from a browser for the purpose of providing 
additional functionality to the browser. The key ctifierences 
between a helper application or sometimes called a viewer 
and a plug-in are: 

How the program is integrated with the Web browser — 
unlike a plug-in, a helper application is not integrated 
with the Web Browser, although it is laimched firom a 
Web browser. A helper application generally runs in its 
own window, contrary to a plug-in which is generally 
integrated into a Web page. 
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How the program is installed — ^like a plug-in, the user 
installs the helper application. However, because the 
helper application is not integrated with the browser, 
the user tends to do more work during installation 
specifying additional information needed by the 
browser to launch the helper application. 
How the program is initiated — the user tends to initiate 
the launching of the helper application, unlike a plug-in 
where the browser does the initiation. 
From where the program is executed — the same helper 
application can be executed from a variety of browsers 
without any updates to the program, unlQce a plug-in 
which generally needs to be updated for specific brows- 
ers. However, helper applications are still operating 
system dependent. 
Java applet — ^a program written in Java that runs within or 
is launched firom the client's browser. This program is 
loaded into the client device's memory at runtime and then 
unloaded when the application shuts down. A Java applet 
can be as simple as a cool animated object on an HTML 
page, or can be as complex as a complete windows appli- 
cation running within the browser. 

ActiveX control — ^is also a program that can t>e run within 
a browser, from an application independent of a browser, or 
on its own. ActiveX controls are developed using Microsoft 
starKlards that define how rc -usable softwarc components 
should be built. Wthin the context of a browser, ActiveX 
controls add ftmctionality to Web pages. These controls can 
be written to add new features like dynamic charts, anima- 
tion or audio. 

Implementation Cbnsiderations 

Viewers and plug-ins are some of the most dynamic 
segments of the browser market due to quickly changing 
technologies and companies. What was yesterday a plug-in 
or a viewer add-on often becomes a built-in capability of the 
browser in its next release. 

Exemplary products that may be used to implement this 
component include Real Audio Player; VDOLive; Macro- 
media Shockwave; Internet Phone; Web 3270. 

Real Audio Player — a plug-in designed to play audio and 
video in rcal-time on the Internet without requiring to 
download the entire audio file before you can begin 
listening, or a video file before you can begin viewing. 
Macromedia Shockwave — a plug-in used to play back 
complex multimedia documents created using Macro- 
media Director or other products. 
Internet Phone — one of several applications which allow 
two-way voice conversation over the Internet, similar 
to a telephone call. 
Web3270 — a plug-in from Information Builders that 
allows mainframe 3270-based applications to be 
viewed across the Internet from within a browser. The 
Web3270 server provides translation services to trans- 
form a standard 3270 screen into an HTMI^based 
form. Interest in Web3270 and similar plug-ins has 
increased with the Internets ability to provide custom- 
ers and trading partners direct access to an organiza- 
tions applications and data. Screen scraping plug-ins 
can bring legacy applications to the Internet or intranet 
very quickly. 
Form 1312 

like Form Services outside the Web Browser, Form 
Services within the Web Browser enable applications to use 
fields to display and collect data. The only difference is the 
technology used to develop the Forms. The most common 
type of Forms within a browser are Hypertext Markup 
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Language (HTML) Forms. The HTML standard includes into and around virtual stores, or flying around a 3-D virtual 

tags for informing a compliant browser that the bracketed resort complex you are considering for a holiday, 

information is to be displayed as an editable field, a radio To create sophisticated user navigation interfaces such as 

button, or other form-type control. Currently, HTML brows- these requires additional architectural services and lan- 

ers support only the most rudimentary forms — basically 5 guages. The Wtual Reality Modeling Language (VRML) is 

providing the presentation and collection of data without oug such language gaining in popularity, 

validation or mapping support. When implementing Forms Implementation Considerations 

with HTML, additional services may be required such as The hyperlink metaphor makes it possible for the user to 

client side scripting (e.g., VB Script, JavaScript). jump from topic to topic instead of reading the document 

Additionally Microsoft has introduced ActiveX docu- 10 begirming to end. For many types of applications, this 

ments which allow Forms such as Word documents. Excel can create a more user-friendly interface, enabling the user 

spreadsheets, Visual Basic windows to be viewed directly lo fi°d information faster. 

from Internet Explorer just like HTML pages. An image map menu can be useful where all users share 

Different technologies may be used to create Forms that some visual model for how business is conducted, and can 

are accessible outside of the browser from those that are 15 be very engaging, but also painfully slow if even a moderate 

accessible within the browser However, with the introduc- speed communications cormection is required. Additional 

tion of ActiveX documents these differences are getting Image Map Services are required to map the location of user 

narrower. mouse clicks within the image to the corresponding page or 

Exemplary products that may be used to implement this window which is to be launched, 

component include JetForms JetForm Design; Lotus Forms; 20 Exemplary products that may be used to implement this 

Yisual Basic; Front Page. component include Silicon Graphics Open Inventor; 

FrontPage— Web site management tool that supports web VREAM VRCreator, DimensionX Liquid Reality, 

page creation, web site creation, page and link man- There are many toolkits and code libraries available to 

agement and site administration. speed development of applications utilizing Reality services. 

User Navigation 1314 25 ^1°^ are some representative products: 

Like User Navigation Services outside the Web Browser, Silicon Graphics Open Inventor — an d^ject-oriented 3-D 

User Navigation Services within the Web Browser provide toolkit used to build interactive 3-D graphics using 

a user with a way to access or navigate between frmctions objects such as cameras, lights and 3-D viewers; pro- 

within or across applications. These User Navigation Ser- vides a simple event model and animation engine, 

vices can be subdivided into three categories: 30 VREAM VRCreator — a toolkit for building interactive 

Hyperlink — the Internet has popularized the use of under- virtual reality environments; supports gravity, 

lined key words, icons and pictures that act as links to further elasticity, and throw-ability of objects, textured and 

pages. Tlie hyperlink mechanism is not constrained to a colored 3-D objects and construction of networked 

menu, but can be used anywhere within a page or document multi-participant worlds. Provides support for ActiveX, 

to provide the user with navigation options. It can take a user 35 DimensionX Liquid Reality — ^VRML 2.0 platform writ- 

to another location within the same document or a different ten in Java, which provides both a viewer for viewing 

document altogether, or even a different server or company VRML content and a toolkit of Java classes for creating 

for that matter. There are three types of hyperlinks: powerful 3-D applications. It supports more than 250 

Hypertext is very similar to the concept of Context classes for 3-D content creation. 

Sensitive Help in Windows, where the reader can move from 40 Report and Print 1316 

one topic to another by selecting a highlighted word or Report and Print Services support the creation and 

phrase. on-screen previewing of paper or photographic documents 

Icon is similar to the hypertext menu above, but selections which contain screen data, application data, graphics or 

are represented as a series of icons. The HTML standard and images. 

popular browsers provi(k hyperlinking services for non-text 45 Implementation Considerations 

items such as graphics. Printing services must take into consideration varying 

Image Map is also similar to the hypertext menu above, print scenarios common in Netcentric environments, inchid- 

but selections are represented as a series of pictures. A ing: varying graphics/file types (Adobe .PDF, .GIF, JPEG), 

further evolution of the image map menu is to display an page margins and breaks, HTML constructs including tables 

image depicting some place or thing (e.g., a pichire of a bank 50 and frames, headers/titles, extended character set support, 

branch with tellers and loan officers). etc. 

Customized Menu — a menu bar with associated pull- Is there a need for reporting or decision support? 

down inenus or context-sensitive pop-up menus. However, Use report writers when you need to transform user data 

as mentioned earlier this method hides functions aiKl options into cohmmar reports, forms, or mailing lists that may 

within menus and is-difScult for infrequent users. Hierefore, 55 require sophisticated sorting and formatting facilities. This 

it is rarely used directly in HTML pages, Java applets or generally occurs for two reasons. The first is building 

ActiveX controls. However, this capability might be more "production reports" (i.e., reports that are built once and then 

applicable for intranet environments where the browsers used repeatedly, generally on a dailyAveekly/monthly basis), 

themselves need to be customized (e.g., adding custom The second is ad hoc reporting and decision support. Prod- 

pull-down menus within Internet Explorer) for the organi- 60 ucts targeted at one or the other use will have different 

zations specific business applications. facilities, (source is market research) 

Mrtual Reality — A virtual reality or a virtual environment Is there a need to ease access to corporate data? 

interface takes the idea of an image map to the next level by Use report writers when users require easy and quick 

creating a 3-dimensional (3-D) environment for the user to access to corporate data. Since developers can deliver 

walk around in. Popularized by PC games like Etoom, the 65 reports as run-time applications, users are shielded from 

virtual envirormient interface can be used for business having to learn complicated daUbases in order to access 

applications. Imagine walking through a shopping mall and information. All a user has to do to retrieve the data is click 
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on an icon to launch a report. Because these run-time Supported report types 

applications are smaller than normal applications, they Aggregate functions. 

launch faster and require very littie training to operate. Is the intention to create production reports or facilitate 

(source is market research) end user queries? 

Product Cbnsiderations 5 Ease of use will be of major importance for end user query 

Buy vs. Build and decision support type applications. In contrast, func- 

There are numerous packaged controls on the market tionality that allows for the implementation of complex 

today that support basic report and print capability. reporting requirements will outweigh ease of use for appli- 

However, a careM evaluation of both fimctions and features cations whose objet^ive is creating production reports, 

and vendor viability must be completed before a decision 10 Direct Manipulation 1318 

can be ma(fc. Architects must additionally be sure to evalu- Direct Manipulation Services enable applications to pro- 
ate that controls will support all required environments, are vide a direct manipulation interface (often called "drag & 
small in size and extensible as requirements demand. drop*^. A direct manipulation interface allows xisers to 
How important is performance? manage multiple "application (Ejects" by manipulating 
In general, performance of data access and printing should is visual representations of those objects. For example, a user 
be considered. Some typical benchmark tests include table may sell stock by dragging "stock" icons out of a "portfolio" 
scan, single-table report, joined table report, and mailing icon and onto a "trading floor" icon. Direct Manipulation 
label generation times, (source is market research) Services can be further divided as follows: 

What is the budget? Display: These services enable applications to represent 

Per developer costs as well as run time licensing fees, 20 application objects as icons and control the display cbarac- 

maintenance costs, support fees, and upgrade charges should teristics (color, location, etc.) of these icons, 

be considered. InputA^alidation: These services enable applications to 

Do I have another component that satisfies this require- invoke validation or processing logic when an end user "acts 

tacni? on" an application object. "Acting on" an object may include 

Many databases and application development tools are 25 single clicking, double clicking, dragging, or sizing, 

shipped with built in or add-on report writing capability. Input Device 1320 

However, stand-alone report writers: (1) are more powerful Detect user input foom a variety of input technologies (i.e. 

and flexible, especially when dealing with multiple data pen based, voice recognition, touch-screen, mouse, digital 

sources and a wide variety of formats; (2) can retrieve camera, etc.). 

information from more data sources than the bundled report 30 Implementation Cbnsiderations 

writers and can create reports from several data sources Voice response systems are used to provide prompts and 

simultaneously; (3) excel in ease of use, both in designing responses to users through the use of phones. Voice response 

and generating reports; (4) offer better tools and more systems have scripted call flows which guide a caller 

predefined reports; and (5) have faster engines, (source is through a series of questions. Based on the users key pad 

market research)s 35 response, the voice response system can execute simple 

Does the product integrate with the existing or proposed calculations, make daUbase calls, call a mainframe legacy 

architecture? application or call out to a custom C routine. Leading voice 

It is important to consider how well a product integrates response system vendors include VoioeTek and Periphonics. 

with desktop tools (word processing, spreadsheet, graphics Voice recognition systems are becoming more popular in 

etc.) and application development programs. These items 40 conjunction with voice response systems. Users are able to 

can be used to extend the capabilities of the reporting speak into the phone in addition to using a keypad, \bice 

package. recognition can be extremely powerful technology in cases 

What databases does the product support? where a key pad entry would be limiting (e.g., date/time or 

A product should support the most widely used PC file location). Sophisticated voice recognition systems have 

formats and Client/Server databases. It may be necessary to 45 been built which support speaker-independence, continuous 

consider the type of support. For example, native database speech and large vocabularies, 

interfaces tend to have better performance than open stan- Information 10(]!2,1004 

dards such as ODBC. Another possible consideration is how FIG. 14 illustrates several components of the Information 

well the product accesses multiple files or databases, (source Services of the present invention. Information Services 

is market research) 50 manage electronic data assets and enable applications to 

What are the required features of the tool? access and manipulate data stored locally or remotely in 

Features to look for include but are not limited to: documents or databases. They minimize an application's 

WYSIWYG print preview dependence on the physical storage and location within the 

Ability to create views — prevents users from getting network. Information Services can be grouped into two 

overwhelmed with choices when selecting a table, acts categories: Database Services, and Document Services, 

as a security system by controlling which users have Database Services 14tt2 

access to certain data, and increases performance since Database Services are responsible for providing access to 
only the data users need gets downloaded to the report ^ ^ remote database, maintaining integrity of the 
engine, thereby reducing network traffic. within the database and supporting the ability to store 
Data dictionary— store predefined views, formats, and ^ ^^^^ ^^^^^ ^ physical platform, or in some cases 
table and field name ahases. multiple platforms. These services are typically pro- 
User friendly query tool ^fff vendors and accessed via embedded or 
„ . . , call-level SQL vanants and supersets. Depending upon the 
Scnptmg or macro language underlying storage model, non-SQL access methods may be 
Supported data types and formats ^ instead. 

Formatting capabilities (page orientation, fonts, colors. Many of the Netcentric applications are broadcast-type 

margins, condensed printing, etc.) apphcations, designed to market products and/or publish 
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policies and procedures. Furthermore, there is now a growth Synchronization Services perform the transactions 

of Netcentric applications that are transaction-type applica- required to make one or more information sources that are 

tions used to process a customers sales order, maintenance intended to mirror each other consistent. This function may 

request, etc. TypicaUy these type of applications require especiaUy valuable when implementing appHcations for 
iSd^e ^ manager. Database Services 5 usersof mobile devices because it allows a working ra^^ 

c«- Tj* c - o or documents to be available locally without a constant 

^ ^ allow teams to collaborate and share knowledge has height- 
Implementation Cbnsiderations ^"^^f. ^^'^ ^""^ Synchronization Services in the execution 

The core database services such as Security, Storage and ^° architecture. 
Access are provided by all major RDBMS products, . Replication and Synchronization are used 
whereas the additional services of Synchronization and interchangeably, depending on the vendor, article, book, etc. 
Replication are available only in specific products, example, wheii Lotus Notes refers to Replication, it 
Product Considerations means botii a combination of Replication and Synchroniza- 
Oracle 7.3; Sybase SQL Server, Informix; IBM DB/2; tion Services described above. When Sybase refers to Rep- 
Microsoft SQL Server lication it only means copying data from one source to 
Oracle 7.3 — market leader in the Unix client/server another. 

RDBMS market, Oracle is available for a wide variety Implementation Consideration 

of hardware platforms including MPP machines. Replication/Synchronization Services are sometimes sup- 
Oracles market position and breadth of platform sup- 20 plied as part of commercial databases, document manage- 

port has made it the RDBMS of choice for variety of ment systems or groupware products such as Lotus Notes, 

financial, accounting, human resources, and manufac- Microsoft Exchange, Oracle, etc. 

turing application software packages. Informix— With Windows 95 and Windows NT 4.0, Microsoft has 

second in RDBMS market share after Oracle, Informix also introduced the concept of ReplicationySynchronization 
IS often selected for its ability to support both large 25 Services into the operating system. Through the briefcase 

centralized databases and distributed environments appHcation users can automatically synchronize files and 

with a smgle RDBMS product. Sybase SQL Server— SQL data between their Windows PC and a Windows NT 

third m RDBMS market share, Sybase traditionaUy server. Underlying this application is the usernextensible 

focused upon medium-sized databases and distributed Win32 synchronization services API which can be used to 
environments; it has strong architecture support for 30 build custom synchronization tools, 

database replication and distributed transaction pro- Are changes in data usage anticipated'' 

cessing across remote sites. Data can be dynamically changed to accommodate 

IBM DB2 — the leader in MVS mainframe database changes in how the data is used 

management, IBM DB2 family of relational database Is it desirable to shield the user from the data access 
products are designed to offer open, industrial strength 35 process? 

database management for decision support, transaction A replicated database often consolidates data from het- 
processing and line of business applications. The DB2 erogeneous data sources, thus shielding the user fi-om the 
family now spans not only IBM platforms like personal processes required to locate, access and query the data, 
computers, AS/400 systems, RISC System/6000 hard- What are the availability requirements of the system? 
ware and IBM mainframe computers, but also non- 40 Replication provides high availability. If the master data- 
IBM machines such as Hewlett-Packard and Sun base is down, users can still access the local copy of the 
MiCTOsystems. Microsoft SQL Server— the latest ver- database. 

sion of a high-perfoniiance client/server relational Is there a business need to reduce communication costs? 

database management system. Building on version 6.0, Depending on the configuration (real time vs. nightly 

SQL Server 6.5 introduces key new features such as 45 replication, etc.), there is a potential to reduce communica- 

transparent distributed transactions, simplified tions costs since the data access is local, 

administration, OLE-based programming interfaces. Is scalability an issue? 

improved support for industry standards and Internet With users, data, and queries spread across multiple 

integration. computers, scalability is less of a problem. 

Replicatioii/Synchronization 1404 50 Can users benefit from the increased performance of local 

Replication Services support an environment in which data access? 
multiple copies of databases must be maintained. For Access to replicated data is fast since data is stored locally 
exarnple, if ad hoc reporting queries or data warehousing and users do not have to remotely access the master data- 
applications can work with a replica of the transaction base. This is especially true for image and document data 
database, these resource intensive applications will not inter- 55 which caimot be quickly accessed from a central site, 
fere with mission critical transaction processing. Replication Making automatic copies of a database reduces locking 
can be either complete or partial. During complete replica- conflicts and gives multiple sets of users better performance 
tion all records are copied from one destination to another, than if they shared the same database, 
while during partial replication, only a subset of daU is Product Considerations 

copied, as specified by the user or the program. Replication 60 What is the current or proposed environment? 

can also be done either real-time or on-demand (i.e., initiated Platforms supported as well as source and target DBMS 

by a user, program or a scheduler). The following might be should be considered. 

possible if databases are replicated on alternate server(s): What are the technical requirements? 

better availability or recoverability of distributed applica- Products differ in features such as complete refresh vs. 

tions; better performance and reduced network cost, particu- 65 differential refresh (replication of changes), replication 

larly in environments where users are widely geographically granularity (row, table, database), method of capturing 

dispersed; etc. changes (snapshot, SQL statement intercept, trigger-based. 
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log-based), method of propagating copies (push, pull), database. Currently there are three contending archi- 

propagation timing controls (database event-driven, sched- tectures for providing gateway functions: 

uled based on interval, scheduled based on application Distributed Relational Data Access pRDA) is a standard 

event-driven, manually invoked), and conflict resolution promoted by IBM for distributed data access between 

mechamsms. Also important is what management utilities 5 heterogeneous databases. In this case the conversion of 

are available with the product the format and protocols occurs only once. It supports 

Arc available resources and issue? SQL89 and a subset of SQL92 standard and is built on 

Products vary m the amount of resources required to top on APPC/APPN and TCP/IP transport stacks. 

XT '^'^ . . EDA/SQL and the Sybase/MDI Open Server use 

What arc the busme^ requirements? lo ^ relational and non-rehiional database 

Three key considerations are: xi,^,, Amjcr\i ^^o/^T i 

^ systems. They use API/SQL or T-SQL respectively as 

Who owns and uses the data? Replication products sup- the standard interface language. A large number of 

port one or more of the three ownership motfels: communication protocols are supported including 

Primary site ownership--<iata is owned by one site; NetBIOS, SNA, DecNET, TCP/IP. The main engine 

Dynamic site ownership-^ata owned by one site, 15 translatestheclientrequestsintospecificservercalls.lt 

however site location can change; and Shared site handles security, authentication, statistics gathering ami 

ownership— data ownership is shared by multiple sites. some system management tasks. 

Which of the four basic types of replication style is Implementation Considerations 

appropriate? The four styles are: Data dissemination— Gateways may create bottlenecks, because all the clients 

portions of centrally maintained data are replicated to go through a single gateway, 

the appropriate remote sites; Data consolidation — data Security 1410 

is replicated firom local sites to a central site where aU Security Services enforce access control to ensure that 

local site data is consoUdated; Replication of logical records are only visible or editable by authorized people for 

partitions-replication ofpartitioned data; and Update approved purposes. Most database management systems 

anywhere^ultiple remote sites can possible update provide access control at the database, table, or row level as 

same data at same time. well as concurrency control. 

What is the acceptable latency period (amount of time the Implementation Considerations 

primary and target data can be out of synch)? There are Will the application be used in a distributed environment? 
three basic repUcation styles depending on the amount 3^ in a distributed environment, the need exists to provide 

of latency that is acceptable: Synchronous^eal-time access to the corporate data and resources in a secure and 

access for all sites (no latency); Asynchronous near controlled manner. This access depends on the role of the 

real-time— short period of latency for target sites; user, the user group, etc. within that environment. Since 

Asynchronous batch/periodic-^redetermined period security is an architecture component where functionality 

of latency for all sites. and robustness vary across engagements, the architectures 

Do I already have a component that satisfies this criteria? usuaUy provide a base set of security functions. These 

Many DBMS vendors ship repUcation products as either functions target securing the systems coqx)rate data and 

part of the base package or as an additional feature. rcsources, as opposed to securing an applications detaHed 

Possible Product Options functions. 

Sybase Replication Server, Oracle Symmetric RepHcation; ^ The security component prcvents unauthorized users from 

CA-Ingrcs Repticator, InfoPump; DataPropagator Rela- accessing corporate data/resources by providing the users 

tional; Informix Replicator with access codes-password & ID--that allows the user to 

Access 1408 login to the system or execute any (or a particular) appli- 

Access Services enable an application to retrieve data cation. 

firomadaUbaseaswellasmanipulate(insert,update,delete) ^^^iy components can restrict access to functions 

data m a database. SQL is tiie pnmary approach for access- ^thin an application based on a users security level. The 

mg records m today's database management systems. highest level security is whetiier the user has access to run 

Client-server systems ofteri require data a^ fern the application. The next level checks if the user has access 

multiple databases offeredbydifferentvendors. This isoften to functions within the application, such as service calls or 

due to mtegrauon of new systems with existing legacy windows. At an even lower level, the security component 

systems. The key architectural concern is m building the ^^i^ ^heck security on more granular functions, such as 

application where the mulU-vendor problem is transparent to widgets on a window 

the client. This provides future portability, flexibifity and ^^^^^ ^^^^^ ^^^^ 

also makes It easier for appbcaUon developers to wnte to a i^tform in a distributed environment. True security should 

smgledaubase access interface. Achieving database access ^ ^e placed on the server platform, to protect the 

transparency requires the followmg: ^^^^ ^^^^^ ^^^^^^ appHcation. 

Standards Based SQLAPI—this approaches uses a single, is there a dircct/indirect relationship between the user 

standards based set of APIs to access any database, and role/group and the data/services? 

includes the foUowing technologies: Open Database There are situations where it is required for the system to 
Connectivity (ODBQ, Java Database ConnecUvity ^ maintain the relationship of the users role and the users 

(JDBC), and Object Linking and Embedding (OLE access to specific system services/resources. For example, a 

^^)* database administrator will have read-write-delete access to 

SQL Gateways provide a mechanism for clients to trans- the database, whereas a sales manager will have only read 

parentiy access data in a variety of databases (e.g., access to it for viewing the data in various forms. The 
Oracle, Sybase, DB2), by translating SQL calls written 65 security component should provide the functionality for 

using the format and protocols of the gateway server or vatidating the users resource access privileges based on the 

primary server to the format and protocols of the target role of the user. 
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Indexing 1412 Synchronization Services perform the transactions 

Indexing Services provide a mechanism for speeding up required to make one or more information sources that are 

data retrieval. In relational databases one or more fields can intended to mirror each other consistent. They support the 

be used to construct the index. So when a user searches for needs of intermittently connected users or sites. Just like for 

a specific record, rather than scanning the whole table 5 databases, these services are especially valuable for users of 

sequentially the index is used to find the location of that mobile devices that need be able to work locally without a 

record faster. constant network connection and then be able to synchronize 

Storage 1414 ^^jj central server at a given point in time. 

Storage Services manage data physical storage. These Implementation Considerations 

services provide a mechanism for saving information so that Products such as Lotus Notes and Microsoft Exchange 

data will live beyond program execution. Data is often allow remote users to lephcate documents between a cUent 

stored m relational format (an RDBMS) but may also be machine and a central server, so that the users can work 

stored in an object-onented format (OODBMS) or other disconnected &om the network. When reattached to the 

formats such as IMS, VSAM, etc. network, users perform an update that automatically 

Document Services 1416 ^5 exchanges information on new, modified and deleted docu- 

Document Services provide similar structure and control ments. 

for documents that database management systems apply to Note: Both Lotus Notes and MS Exchange provide a 

record onented data. A document is defined as a collection limited subset of the Document Services described in this 

of objects potentially of different types (e.g., structured data, section. This should be carefiiUy evahiated when consicfer- 

unstructured data, images, multi-media) a business user ^ mg these products to provide document management ser- 

deals with. An individual document might be a table created vices, 

using a spreadsheet package sudi as Microsoft Excel, a Access 1408 

report created using a word processing package such as Access Services support document creation, maintenance 
Lotus AmiPro, a Web page created using an HTML author- and retrieval. These services aUow users to capture knowi- 
ng tool, unstructured text or a combmation of these object 25 edge or content through the creation of unstructured 
types. Regardless of the software used to create and maintain information, i.e. documents. Access Services allow users to 
the component parts, aU parts together constitute the effectively retrieve documents that were created by them and 
document, which is managed as a smgle entity. documents that were created by others. Documents can be 
Netcentnc applications that are executed from a browser comprised of many different data types, including text, 
are particularly well suited for servmg up document style 30 charts, graphics, or even audio and video, 
information. If the Web application consists of more than Security 1410 

just a few HTML documents, integration with a document Documents should be accessed exclusively through the 

management system should be considered. Document Ser- document management backbone. If a document is checked- 

vices include: Storage Services, Indexing Services, Security m^ check-out, routed, viewed, annotated, archived, or 

Services, Access Services, Replication/Synchronization 35 primed it should be done only by users with the correct 

Services, and Versionmg Services. security privileges. TTiose access privileges should be able to 

Possible Product Options be controlled by user, role, and group. Analogous to record 

Documentum Server; Saros; PC Docs locking to prevent two users from editing the same data, 

Documentum — Documentum Enterprise Document Man- document management access control services include 

agement System (EDMS) automates and accelerates 40 check-in/check-out services to limit concurrent editing. 

the creation, modification, and reuse of business- Indexing 1412 

critical documents, Web pages, and other unstructured Locating documents and content within documents is a 

data and all of the collaborative efforts involved. more complex problem and involves several alternative 

Saros — Saros Discovery Suite is the next generation methods. The Windows file manager is a simplistic imple- 

client/server solution that integrates Saros Document 45 mentation of a hierarchical organization of files and collec- 

Manager, FileNet Ensemble and Watermark tion of files. If the user model of where documents should be 

Qient to provi(k powerful, tightly-integrated electronic stored and found can be represented in this way, the use of 

document management, workflow, and. document- stmcture and naming standards can be sufficient. However, 

imaging capabilities. a hierarchical document filing organization is not suitable 

Versioning 1418 50 for many types of document queries (e.g., retrieving all sales 

Versioning Services maintain a historical record of the order documents for over $1,000). 

changes to a document over time. By maintaining this Therefore, most document management products provide 

record, these services allow for the re-creation of a docu- index services that support the following methods for 

ment as it looked at any given point in time during it's searching document repositories: 

evolution. Additional key versioning features record who 55 Attribute Search— scans short lists (attributes) of impor- 
made changes when and why they were made. tant words that are associated with a document and 
Replication/Synchronization 1404 returns documents that match the search criteria. For 
Replication Services support an environment in which example, a user may query for documents written by a 
multiple copies of documents must be maintained. A key specific author or created on a particular date. Attribute 
objective is that documents should be shareable and search- 60 search brings the capabilities of the SQL-oriented data- 
able across the entire organization. Therefore, the architec- base approach to finding documents by storing in a 
ture needs to provide logically a single repository, even database the values of specially identified fields within 
though the documents are physically stored in different a document and a reference to the actual document 
locations. The following might be possible if documents are itseff. In order to support Attribute Search an index 
replicated on alternative server(s): better availability or 65 maintains documents' attributes, which it uses to 
recoverability of a distributed apptication; better perfor- manage, find and catalog documents. This is the least 
mance; reduced network cost; etc. complicated approach of the searching methods. 
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Full-text Search— searches repository contents for exact such as Oracle or Sybase. Attributes are stored within 

words or phrases and returns documents that match the traditional database data types (e.g., integer, character, 

search criteria. In order to facilitate Fidl-text Search, etc.); contents are stored in the database's BLOB 

full-text indexes are constructed by scanning docu- (Binary Large Objects) data type, 

ments once and recording in an index file which words 5 Industry standard database and file system — ^Documents* 
occur in which documents. Leading document manage- attributes are stored in an industry standard database, 

ment systems have full-text services built-in, which can and documents' contents are usually stored in the 

be integrated directly into applications. file-system of the host operating system. Most docu- 

Context Search— searches repository contents for exact management products use this document storage 

words or phrases. Also, searches for related words or lO because today, this approach provides the most 

phrases by using synonyms and word taxonomies. For flexibility m terms of data distribution and also allows 

examje^^ ComSSn^S 

should look for car, automobile, motor vehicle, etc. ^s iUustrated in FIG. 15, Network services provided by 

Boolean Search— searches repository contents for words the Communications Services layer are grouped into four 

or phases that are joined together using boolean opera- major categories of functionality: Virtual Resource, 

tors (e.g., AND, OR, NOT). Same type of indexes are Directory, Messaging, and Security services 1502,1504, 

used for Boolean Search as for Full-Text Search. 1506,1508. 
The following products are used to index and search Web Virtual Resource services proxy or mimic the capabilities 

and non-Web documents: of specialized, network coimected resources. This allows a 

\ferity Topic — delivers accurate indexing, searching and ^ generic network node to emulate a specialized physical 

filtering of a wide variety of information sources and device. In this way, network users can interface with a 

formats. Verity Topic is integrated direcUy into several variety of ^dalized resources. 

document management products, aUowing systems to , Directory services play a key role in network architectures 

full-text index its unstructured information. Verity ^^^^ °^ theu- abiUty to umfy and manage distributed 

Topic also offers a variety of products to help fuU-tejrt ^ environments Managing information about network 

index Web sites resources mvolves a vanety of processes ranging from 

.,* . - ^ simple name/address resolution to the logical integration of 

Fulcaim-provides a variety of rebust, muhi-platform heterogeneous systems to create a common view of services, 

mdexmg and retrieval products that dehver fiiU- security, etc. 

function text retrieval capabiHties. Fulcrums products ^ Messaging services transfer formatted information from 

arc typicaUy mtegrated with custom databases, Web one process to another. These services shield applications 

sites and document management systems. from the complexity of the network transport services. 

Ihe following products are mainly used for Web docu- Call centers and customer service centers are integral 

ments: parts of many business operations. Call centers have 

Microsoft Index Server 1.1 — allows for search of Web - erihanced business processes by managing telephone contact 
documents, including Microsoft Word and Microsoft ^ potential customers, with the objective of improving 

Excel. It works with Windows NT Quality of Service (QoS). Several customer and business 

Server 4.0 and Internet Information Server 2.0 or higher ^""T ^ "motivating a transition from traditional cost- 
to provide access to documents stored on an intranet or "^"^^^ ""^^^ ^^^^^"^ 0° 

fritemet site. Index Server supports fidl-text searches ^ ^r^Ziinl^^tW • 

and retrieves Jl tyi- of info^ation from the Web ^ oetSkTtl^c^"'^^ 

O^^o^^^S^in"^^^^ ^^-^-^ servi^swiths^ty^r^^sm^ 

<^ . , o B"i" "">u»i- architecture (e.g., application and database layers) results in 

Netscape Catalog Server 1.0— provides an automated robust security 

searchanddiscovetyserv6rforcreating.managiiig,and 45 Implementation Considerations 

keeping current an online catalog of documents resid- ^ translation required? 

uig on roiporate intranets and the Internet. Catalog Communications middleware can translate data into a 

Server offers query by full teirt, category, or attributes fonnat that is compatible with the receiving process. This 

sich as Utle. author dale, etcjtakosuppoite multiple ^.ay be required in a heterogeneous enWJonment. An 

file fw-mats. including HTML, Word. Excel, 50 example is data translation fiom ASCT-to-EBCDlC. It is 

FowerPomt, and PDF. important to note that data translation may not be provided 

Storage 1414 by all middleware products. 

Storage Services manage the document physical storage. Are additional communications services required? 

W^ast document management projhicts store documents as Communications middleware can provide additional 

objects that mclude two basic data types: attributes and 55 communications services that may be required by the appU- 

contenL Document attributes are key fields used to identify cations. Additional services include dynamic mesMge 

the document such as author name, created date, etc. roudng. guaranteed delivery, broadcasting, queuing, and 

Document content refeis to the achial unsfructured mfonna- priority delivery. TTK^se common services are usuaU? pro- 

Uon stored within the document. GeneraJly the documents yided in the communications middleware rather than 

are stored in a repository using one of the following meth- «, addressing them in each application separately. Different 

communications middleware products provide different ser- 

Proprietary database— documents (attributes and vices. AdditionaUy, many middleware packages such as 

contents) are stored m a propnetary database (one that Tuxedo, provide OLTP functionary, 

the vendor has specificaUy developed for use with their Is a packaged middleware solution desired? 

product). g5 Depending on the functionality required, communications 

Industry standard database— documents (attributes and middleware can be very complex to custom develop. In 

contents) are stored in an industry standard database addition, products have evolved to a point where proven 
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solutions exist. Based on this, it can be desirable to buy 
communications middleware rather than to build it. Consid- 
erations of time, budget, skills, and maintenance shoiild be 
taken into account when selecting between a packaged 
middleware product and custom developed middleware. In s 
some instances, custom developed middleware may still be 
preferred. 

What is the clients middleware direction? 

There is a definite functionality overlap between commu- 
nications middleware and several other middleware compo- lo 
nents sudi as transaction services and information access. In 
addition, communications middleware may be provided by 
various CASE tools. An example of this is the Distribution 
Services component of FCP. Because of this overlap, it is 
important to understand the clients overall direction toward 15 
middleware and the specific middleware functionality 
required by the overall solution. 

Is a simplified developers interface important? 

Tlie simplified interface associated with communications 
middleware can help to reduce the complexity of developing 20 
Netcentric applications. The simplified interface helps 
reduce the development complexity by insulating the busi- 
ness applications from the network protocols. Because of 
this, application developers do not need to understand the 
intricacies and somewhat cryptic APIs associated with net- 25 
work transport protocols. 

Is location transparency required? 

Communication middleware allows the client application 
to access any service on any physical server in the network 
without needing to know where it is physically located. This 30 
capability may be required in an environment with many 
physical servers or in an environment that is very dynamic. 
It is important to note that location transparency may not be 
provided by aU middleware products. 

Does the application need to run on multiple platforms? 35 

Conmiunications middleware is designed to allow appli- 
cations to access various tran^rt protocols firom various 
vendois. From a network interface perspective, it should be 
easier to port an application from one computing platform to 
another if the application is using communications middle- 40 
ware. Of course, other porting issues will need to be con- 
sidered. 

^^rtual Resources 1502 

A^rtual Resource services proxy or mimic the capabihties 
of specialized, network-connected resources. This allows a 45 
generic network node to emulate a specialized physical 
device. In this way, network users can interface with a 
variety of specialized resources. An examples of a Mrtual 
Resource service is the capability to print to a network 
printer as if it were directly attached to a workstation. 50 
Fax 1510 

Fax Services provide for the management of both 
in-bound and out-bound fax transmissions. If fax is used as 
a medium for communicating with customers or remote 
employees, in-bound fax services may be required for cen- 55 
trally receiving and electronically routing faxes to the 
intended recipient. Out-bound fax services can be as simple 
as supporting the sharing on the network of a single fax 
machine or group of machines for sending faxes. 

Fax services can provide centrally managed faxing 60 
capabilities, thus eliminating the need for fax modems on 
every workstation. A fax server generally provides Fax 
services to clients, such as receiving, queuing, and distrib- 
uting incoming faxes and queuing and sending outgoing 
faxes. Clients can view faxes and generate faxes to be sent. 65 

y^TpUcations may compose and transfer faxes as part of 
notifying users or delivering information. For example, an 



application may use Fax services to add customer-^ecific 
information to a delivery receipt form and fax the form to a 
customer. 

Implementation Considerations 

More sophisticated out-bound fax architecture services 
are required for supporting fax-back applications. Fax-back 
applications, when coupled with Computer Telephone Inte- 
gration (Cn) are popular for automating customer requests 
for product or service information to be faxed to them. 
Possible Product Options 

Cheyenne Softwares Faxserve; Lotus Fax Server for Lotus 

Notes; Sirens Siren Fax 

The following are examples of fax servers: 

The Lotus® Fax Server (LFS) — provides fax services to 
users working on a networic ruiming NotesMail®. In 
addition to combining outgoing and incoming fax capa- 
bilities in a single product, the LFS provides additional 
features, such as automatic routing, and print-to-fax 
driver software that extends fax capabilities to any 
Windows-based Notes client. The LFS supports a wide 
variety of fax modems, fax cards and fax file formats 
through the incorporation of device technologies from 
Optus Software, Inc. 

Cheyenne Software's Faxserve 

The following is an example of a product that allows 
applications to generate faxes: 

Siren's Siren Fax 
File Sharing 1512 

FIG. 16 illustrates File Sharing services 1512. File Shar- 
ing services allow users to view, manage, read, and write 
files that may be located on a variety of platforms in a variety 
of locations. File Sharing services enable a unified view of 
independent file systems. This is represented in FIG. 16, 
which shows how a client can perceive remote files as being 
local. 

File Sharing services can provide the following capabili- 
ties: 

Tran^arent access — access to remote files as if they were 
local 

Multi-xiser access — distribution and syndironization of 
files among multiple users, including file locking to 
manage access requests by multiple users 

File access control — use of Security services (user 
authentication and authorization) to manage file system 
security 

Multi-platform access — access to files located on various 

platfornis (e.g., UNIX, NT, etc.) 
Integrated file directory — ^a logical directory structure that 

combines all accessible file directories, regardless of 

the physical directory structure 
Fault tolerance — use of primary and replica file servers to 

ensure high availability of file system 
Scalability — ability to integrate networks and distributed 

file systems of various sizes 
Possible Product Options 

Novell's NetWare/IntranetWare; Microsoft's Windows NT 
Server, Sun Microsystems NFS and WebNFS; Novell's 
IntranetWare NFS Services; IBM/Transarcs Distribute 
File System (DFS); Transarc's AFS 
The following are examples of File Sharing products: 
Novell's NetWare/IntranetWare — Novell's NetWare net- 
work operating system includes distributed file 
services, supported by the NetWare Core Protocol 
(NCP). NetWare Directory Services (NDS) manages 
naming and security for files on distributed platforms. 
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Microsoft's Windows NT Server 

Server Message Block (SMB) — native file-sharing pro- 
tocol in Windows 95, Windows NT, and OS/2. 

Common Internet File System (QFS) — an enhancement 
to SMB for distributed file systems in a TCP/IP envi- 
ronment. 

Distributed File System (Dfe) — a utility for Windows NT 
Server that provides file services in a Microsoft envi- 
ronment. 

Network File System (NFS)— NFS is a native UNIX file 
access protocol and is also available as an operating 
system add-on product that provides distributed file 
services. Sun Microsystems introduced NFS in 1985. 
NFS has been widely adopted and has been ported to a 
variety of platforms. 

The following are examples of products that provide NFS 
services. 

Sun Microsystems' NFS and WebNFS Novell's Intranet- 
Ware NFS Services 

AFS — distributed file system for distributed UNIX 
networks; derived from Carnegie-Mellon University's 
Andrew File System. Similar to NFS, but differs in terms of 
the name space, system performance, security, etc. AFS is 
distributed by Transarc. 

IBM/Transarc's Distribute File System (DFS)— a scale- 
able distributed file system that offers replication, security, 
etc. 

Paging 714 

>A^reless ^ort messaging (i.e., paging) can be imple- 
mented through wireless systems such as paging networks, 
GSM voice/data networks, PCS voice/data networks, and 
dedicated wireless data networks. Paging virtual resource 
services provide the message formatting and display func- 
tionality that allows network nodes to interface with wireless 
paging systems. This service emulates the capabilities of 
one-way and two-way pageis. Paging systems allow pages 
to be generated in various ways: 

&mail messages to a specified mailbox 
DTMF (touch tone) signaling to a voice response system 
Encoded digital messages traosfeiied into a paging pro- 
vider gateway 

Messages transferred to a locally attached two-way wire- 
less pager 
Possible Product Options 
TelAlert; E-mail Systems 

e-mail systems — some e-mail systems and fax servers can 
be configured to generate pages to notify users when a 
defined event occurs such as e-mail/fax arriving. 
Telamon's TelAlert — TelAlert provides notification capa- 
bilities for UNIX systems. For example, it can page 
support personnel in the event of system problems. 
Phone 1516 

Phone virtual resource services extend telephony capa- 
bilities to computer platforms. For example, an application 
on a desktop computer can place and receive telephone calls 
for the user. Phone virtual resource services may be used in 
customer care centers, help desks, or any other environment 
in which it is useful for a computer to replace a telephone 
handset. 

Phone services enable clients, servers, and specialized 
telephony nodes (PBXs, ACDs, etc.) to control the tele- 
phony environment through the following telephony con- 
trols: 
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Call control 

Controls telephone features 
Controls recorded messages 

Manipulates real time call activities (e.g., make call, 
answer, transfer, hold, conference, mute transfer, 
release, route call, call treatments and digits 
collected) 
Telephone status control 

Controls telephone status fiinctions 
Logs users in and out of the system 
Sets ready, not ready, and make busy statuses for users 
The following are examples of uses of Phone virtual 
resources: 

PC Telephony — PC telephony products allow desktop 
computers to act as conduits for voice telephone calls. 

Interact Telephony — Interact telephony products enable 
voice telephone calls (and faxing, voice mail retrieval, 
etc.) through the Internet. For example, an Interact 
telephony product can accept voice input into a 
workstation, translate it into an IP data stream, and 
route it through the Internet to a destination 
workstation, where the data is translated back into 
audio. 

Desktop \^ice Mail — Various products enable users to 
manage voice mail messages using a desktop computer. 
Possible Product Options 

Lucent PassageWay; COM2001s TransCOM; NetSpeaks 
WebPhone; VocalTecs Internet Phone; IDTs Net2Phone; 
Octel Communications Unified Messenger 
The following are examples of vendors that provide PC 

telephony products: 

Lucent PassageWay — suite of products that connect PCs 
to PBXs. 

COM2001's TransCOM— voice, data and call- 
management system (dialing, voice mail, faxing, voice 
recognition, caller ID, etc.) for personal computers. 
The following are examples of Interact telephony prod- 
ucts: 

NetSpeak's WebPhone 
VocalTec's Interact Phone 
IDT's Net2Phone 

The following is an example of a desktop voice mail 
product: 

Octel Communication's Unified Messenger 
Terminal 1518 

Terminal services allow a client to connect to a non-local 
host via a network and to emulate the profile (e.g., the 
keyboard and screen characteristics) required by the host 
application. For example, when a workstation apphcation 
logs on to a mainframe, the workstation fimc^ons as a dumb 
terminal. Terminal Services receive user input and send data 
streams back to the host processor. If connecting from a PC 
to another PC, the workstation might act as a remote control 
terminal (e.g., PCAnywhere). 
The following are examples of Terminal services: 
Telnet — a simple and widely used terminal emulation 
protocol that is part of the TCP/IP communications 
protocol. Telnet operates establishing a TCP connection 
with the remotely located login server, minicomputer or 
mainframe. The client's keyboard strokes are sent to 
the remote machine while the remote machine sends 
back the characters displayed on the local terminal 
screen. 

3270 emulation — emulation of the 3270 protocol that is 
used by IBM mainframe terminals. 
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tn3270 — a Telnet program that includes the 3270 protocol spooling print jobs. Related progranos include 1 pr 

for logging onto IBM mainframes; part of the TCP/IP (sends print job to spool) and 1 p (sends request to 

protocol suite. printer). 

X Window System — allows users to simultaneously AudioA^deo 1522 

access applications on one or more UNIX servers and 5 Audio/V^deo services allow nodes to interact with multi- 
display results in multiple windows on a local display. media data streams. These services may be implemented as 
Recent enhancements to XWS include integration with audio-only, video-only, or combined audioMdeo: 
the Web and optimization of network trafSc (caching. Audio services— Audio services allow components to 
compression, etc.). interface with audio streams such as the delivery of 

Remote control — While terminal emulation is typically music or radio content over data networks, 

used in host-based environments, remote control is a Video services— Video services allow components to 

sophisticated type of client/server Terminal service. interface with video streams such as video surveillance. 

Remote control allows a cUent computer to control the Video services can add simple video monitor capabiU- 

processing on a remote de^op computer. The GUI on ties to a computer, or they can transform the computer 

the client computer looks as if it is the GUI on the 15 into a sophisticated video platform with the ability to 

remote desktop. This makes it appear as if the remote generate and manipulate video, 

applications are running on the client Combined AudioA^deo services— Video and audio con- 

rlogin— a remote terminal sendee implemented imder tent is often delivered simulUneously. This may be 

BSD UNIX. The concept behind rlogin is that it sup- accomplished by transferring separate audio and video 

ports "trusted" hosts. This is accomplished by having a 20 streams or by transferring a single interleaved stream, 

set of machines that share common file access rights Examples include video conferencing and television 

and logins. The user controls access by authorizing (traditional or interactive). 

remote login based on a remote host and remote user Audio/N^deo services can include the following function- 
name, ality: 
Possible Product Options 25 Streams content (audio, video, or both) to end users 
Hummingbird's Exc^^^ Computing Devices' Manages buffering of data stream to ensure uninterrupted 
PC-Xware; Citnx WnFrame; Carbon Cbpy; pcANY- viewingAistening 

WHERE; Stac'sReachout; Traveling Software's Laplink ■ a a - va. 

T,ri, - i rvvt^jo. j Performs compression and decompression of data 

The following are examples of X Window System prod- ^ , *^ . . ^, 

yjjjg. Manages conunumcations protocols to ensure smooth 

TT ' Af r A delivery of content 

Hummingbird s Exceed ^ 

Network Cbmpuling Devices' PC-Xware ^^^^ f "^^^ Sea- 

c • 1 r ^ . t J eration of uve content 

The foUowmg are examples of remote control products: k a- nrA % it 

rst * ' w p Audio/Video services draw upon lower-level services 

Utnx s Wint^rame ^^^^ ^ streaming and IP Multicast in order to efficienUy 

Microcom's Carbon Copy deUver content across the network. 

Symantec's pcANYWHERE Possible Product Options 

Stac's Reachout Progressive Networks Real\^deo; Microsoft's NetShow; 

Traveling Software's LapLink Vxtremes Web Theater; Intels ProShare; Creative Labs 

Printing 1520 ^ V^deo WebPhone 

Print services connect network workstations to shared The following products arc examples of video servers: 

printers. The administration of Print Services is usually Progressive Networks' RealVideo 

handled by a print server. Depending on the size of the Microsoft's NetShow 

network and Uie amount of resources the server must Vxtreme's Web Theater 

manage, the print server may run on a dedicated machine or The following products are examples of video conferenc- 

on a machine that performs other server functions. Aprimary jQg systems: 

function of print servers is to queue print jobs sent to Intel's ProShare 

network printers. The queued jobs are stored in a print buffer ^ Ti_*xrj ^^r*^. 

^ . . J * ♦ .u • * *„ 1 Creative Labs Mdeo WebPhone 

on the pnnt server and arc sent to the appropriate network Directory Services 1504 

pnnter as it becomes available. Prmt services can also ^„ a a 11 f *, j i-.- * o • 

providelheclientwithinformationincludingprintjobsutus '° A &U-featu«rf Dujectory Semceorgamzes, categorizes 

and can manage in-progiess print jobs. and names Detworked resources in cider to provide a com- 

PossMe Product Opti^ prehensive picture of clients, servers, users, apphcations and 

NoveU's Netware Distributed Print Services (NDPS); Nov- ^r;^'=^"=fy " database of 

ell's Netware UNIX Print Services; MicroL)ft: Windows „ °bj«cte representing aU nodes and resouro^ on a network. 

NT Server; line Printer Daemon (LPD) " ^ ^f'^ Th^".^ relationships between users and 

rw, f „ . 1 r • * J. . networks, network devices, network applications, and mfor- 

The foUowmg are examples of pnnt server products: ^ *u *, 1 Tn, rx- ^ - 

XT ii» VT ^ Tx- . -L . J iL . ^T.^™,v mation on the network. The Directory service can organize 

Novell s Netware Distributed Print Services (NI)PS>- oetworknodesloreflecttbetopology andoiganization of the 

provides cenual management of pnnt services for Net- ^^^^^^ ^^^^^ Directorf service makes 

are ne orJcs. ^ resources location and platform independent, since it allows 

NoveU's Netware UNDC Prmt Services— a supplement to to locate resources via the directory and regardless of 

NoveU's NetWare 4.1 server which aUows NetWare their physical location. The Directory service also maps 

and UMX chents to share UNIX or Netware prmters. between logical resource names (e.g., «Marketing__Printer") 

Microsoft Windows NT Server— provides central man- and physical resource address (e.g., 10.27.15.56). (See 

agement of print services for NT networks. 65 Name service, below). 

Line Printer Daemon (LPD) — UNIX print management Directory service products utilize Security services to 

facilities, which include client and server utilities for track access rights for access to netwoik resources and 
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information. The Directory service is an efficient way to 
manage resource security, since the directory o£fers a logical 
representation of all resources in the enterprise. In addition, 
the Directory service can act as a single point of entry into 
the network, meaning users can receive access to allowed 
resources by authenticating themselves a single time to the 
Directory service. (For more information on authentication 
and authorization, refer to the Comm. Security service.) 

In summary, the Directory service performs the following 
functions: 

Stores information about network resources and users and 

tracks relationships 
Organizes resource access information in order to aid 

resources in locating and accessing other resources 

throughout the network 
Provides location transparency, since resources are 

accessed through a directory rather than based on their 

physical location 
Converts between logical resource names and physical 

resource addresses 
Interacts with Security services such as authentication and 

authorization track identities and permissions 
Provides single network logon to file and print resources; 

can provide single network logon for network appUca- 

tions that are integrated with the Directory service 
Distributes directory information throughout the enter- 
prise (for reUability and location-independent access) 
Synchronizes multiple directory databases 
Enables access to heterogeneous systems (integration of 30 

various network operating systems, platforms, etc.) 
Directory Starxlards — There are a variety of standards for 
directories. Vendor-specific directory products build upon 
(and extend) standards to provide a robust, fidl-featured 
enterprise directory. 

The following are examples of standards related to Direc- 
tory services: 

X500 an ITU-T standard for a hierarchical directory 
containing user and resource information; includes 
Directory Access Protocol (DAP), which can be used to 40 
access directory information, 
lightweight Directory Access Protocol (LDAP) a de facto 
standard for accessing X500-compatible directory 
information in an Internet/intranet environment. 
Implementation Considerations 

One of the most popular network directory services is 
Novell Directory Services (NDS) used with Netware 4.x. 
This system allows users to access services and resources 
with a single login, regardless of where the user location is 
or where the resource location is. Another example of a 
directory sendee is the ISO XSOO standard. This method is 
not widely used due to its high overheads. In addition to 
these two protocols, \Wndows NT uses a similar system 
called Primary Domain Control. This system allows for the 
same type of directory mapping as NDS and X.500. 

Another protocol that has emerged is the Lightweight 
Directory Access Protocol (LDAP), which is a slimmed- 
down version of the X.500 directory client and is seen as a 
possible replacement for X.500. LDAP is a standard proto- 
col for accessing and updating directory information in a 
client/server environment; it has evolved into an emerging 
standard for directory replication for the Internet, and is 
backed by vendors such as Netscape, Novell, Microsoft, 
IBM and AT&T that can provide low-level compati*bility 
among directory systems. 

Another helpful feature to look out for is support for 
dynamic IP addressing via DHCP. This lets the router handle 
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the process of sharing a small number of IP addresses among 
the members of the workgroup. Support for dynamic IP 
addressing is now part of Windows 95 and Macinto^ 
System 7.6, among other operating systems. 
Possible Product Options 

NoveUs Netware Directory Service; Netscapes Directory 
Server; Microsofts Active Directory; Banyan Systems 
StreetTalk 

The following are examples of products that provide 
full-featured Directory services. 
Novell's Netware Directory Service 
Netscape's Directory Server 

Microsoft's Active Directory Banyan Systems' StreetTalk 
The following is an example of a meta-directory product: 
Zoomit VIA — integrates network operating system 
directories, application databases, and human resource 
databases (includes Lotus cc:Mail, Lotus Notes, Novell 
NDS, Microsoft NT Domain Controller and Active 
Directory, Microsoft Exchange, Banyan VINES, 
Netscape Directory Server), thus allowing unified 
access and maintenance. 
The following are examples of Name services: 
Domain Name Service — ^The most conunon and widely 
used Name Service on the Internet is Domain Name 
Service (DNS) which resolves a pronoimceable name 
into an IP address and vice versa. For instance, DNS 
coidd resolve the domain name of www.ac.com to be 
204.167.146.195. DNS functionality is distributed 
across many computers within the network. 
Microsoft's Windows Internet Name Service (WINS) — 
WINS is Microsoft's proprietary method for mapping 
IP addresses to NetBIOS device names. WINS works 
with Wndows 3.x, Windows 95, and Wndows NT 
clients. 

The following are examples of products that provide 
Domain services: 

Network Information Service (NIS) — Developed and 
licensed by Sun Microsystems for use in UNIX 
envirorunents, NIS tracks user names, passwords, user 
IDs, group IDs, and host names (along with other 
system files) through a centralized NIS database. 

Microsoft's Windows NT Server Domain Controller 
Domain Services 1524 

A network domain is a set of network nodes under 
common control (i.e., common seciuity and logins, unified 
addressing, coordinated management, etc.). Domain ser- 
vices manage these types of activities for the network nodes 
in a domain. Domain services may be limited in their ability 
to support heterogeneous systems and in the ability to scale 
to support the enterprise. 
Name Service 1526 

The Name service creates a logical "pronounceable" 
name in place of a binary machine number. These services 
could be used by other communications services such as File 
Transfer, Message Services, and Terminal Services. A Name 
service can be implemented on its own, or as part of a 
full-featured Directory service. 
Core Messaging 1528 

Broadly defined. Messaging services enable information 
or commands to be sent between two or more recipients. 
Recipients may be computers, people, or processes within a 
computer. Messaging Services are based on specific proto- 
cols. A protocol is a set of rules describing, in technical 
terms, how something should be done. Protocols facilitate 
transport of the message stream. For example, there is a 
protocol describing exactly what format should be used for 
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sending specific types of mail messages. Most protocols Is guaranteed delivery required? 
typically sit "on top" of the following lower level protocol: RPCs do not support guaranteed message delivery tech- 
TCP/IP— Transmission Control Protocol/Lntemet Proto- niques such as store-and-forward and queuing, 
col (TCP/IP) is the principle method for transmitting Consequently, RPCs depend upon the availability of the 
data over the Internet today. This protocol is respon- 5 physical network and server processes. Therefore, network 
sible for ensuring that a series of data packets sent over ^^^^"""^^ fleTi ^^^^ deciding to use RPCs. 

a network arrive at the destination and are properly » i un/- i l 7 -.l . .i 

sequenced *' In general, RPCs work best with Ughdy coupled apphca- 

. *. , - - j.n ^ tions or in environments where significant application modi- 

Messagmg services transfer formatted informaUon from ^^^^^ ^ ^m^ely. RPCs may bTdesirable if the appU- 
one process to another. By drawing upon Messagmg lO nation being developed is intended to be shrink wrapped and 
services, apphcatxons can shield theoiselves from the com- sqIjJ 

plexity of the low-level Tran^ort services. Hie Core Mes- synchronous or asynchronous program control 

saging services category includes styles of messaging that required? 

support basic inter-process communication (IPC). There are Function based middleware such as RPCs traditionally 
a variety of architecture options used to support IPC. They 15 provide synchronous program control. Therefore, they tend 
can be divided into Store and Forward, Synchronous and to pass control from the client process to the server process. 
AsynchroiK)us Message Services. When this occurs, the client is dependent on the server and 

Store and Forward Message Services — provide deferred must wait to perform any additional processing until the 
message service processing. A Store and Forward Message servers response is received. This type of program control is 
Service may use an E-Mail infrastructure upon which to 20 also known as blocking. Some RPC vendors are enhancing 
build applications. Common uses would be for forms rout- products to support asynchronous program control as 

ing and E-mail. well. 

Synchronous Message Services^allow an appUcation to °f conversation control is required? 

send a message to another appUcation and wait for a reply pCs permit one side of the conversation (the cUent) to 
before continuing. Synchronous messaging is typically used ^ request^ while the other side (the server) may 

for update and general business transactions It requires ""^^ F'.'^Z ^P^'^" Co^^^isaUon control is passed from the 
timeout processing to aUow the apphcation to re-a^uire f^""^ ^ 5^^^' ^"^^ request, causes 

. 1 . .. T * f -1 or ^^^^ functions to execute on the server while it waits 

control m the event of failme. for its reply. With RPC^, developers do not need to be 

^Synchronous Message Service allow an apphcaUon to concerned with the state of the conversation between the 
send a message to another apphcation and continue process- 30 ^^^^^ ^^^^ ^ ^^^^ ^^^^^ 

mg before a reply is received. Asynchronous messaging is sation states simplifies the design and development effort, 
typically used for larger retrieval type processing, such as Is yclient interested in a stable or emerging technology? 
retrieval of larger fists of data than can be contained in one RPCs have existed for many years and are considered to 
message. be a mature, stable, proven solution. 

Additionally, inter-process messaging services are typi- it important to minimize development complexity? 

cally one of two messaging types: Due to the synchronous program control and the request/ 

Function Based — ^uses the subroutine model of program- reply conversation control, RPCs can be fairly straightfor- 
ming. The message interface is built upon the calling pro- ward to design and build. The complexity is also reduced 
gram passing the appropriate parameters and receiving the since RPC calls are completely independent of any previous 
returned information. 40 or future RPC call. On the other hand, RPCs usually require 

Message Based-^nessage-based approach uses a defined ^ specific RPC compiler, which may add to the development 
message format to exdiange information between processes. complexity. 

While a portion of the message may be unstructured, a extended technical capabiUties required? 

defined header component is normally included. A message- ^ '^^^ ?},^^ following capabiHtic^ are required, message 
based approach is not limited to the caU/retum structure of 45 based middleware should be considered. It may also be 
the fimction-based model and can be used in a conversa- Possjble to mcorporate thes^ capabihties mto a funcUon 
. I based rmooleware solution, but significant custom modifi- 

on manner. , ^ t_ ^ ^ cation and development may be required. 

Core Messagmg services are categorized b^ Guaranteed Defivery 

tenstics of the mformation bemg transferred: j j 

^ ^ rn Store and Forward 

FUe Transfer 50 

Priority Message Delivery 
Message-Oriented Middleware Dynamic Routing 

Streaming Multicasting and Broadcasting 

How do Messaging services compare to Transaction Pro- 55 Ijoad Balancing 
cessing (TP) services? TP services offer broad functionality Product Considerations 

to support apphcation management, administrative controls. What are the chent's budgetary constraints? 

and appfication-to-application message passing. TP services Costs may vary greatly among middleware products, 

may include global transaction coordination, distributed There are many factors to consider when looking at middle- 
two-phase commit, database support, coordinated recovery 60 ware. To begin, middleware products can require extensive 
after failures, high availabifity, security, and work load consulting and support services just to install. Therefore, 
balancing. TP services may utilize Messaging services, understanding the set-up and configuration costs are impor- 
which provide basic interprocess communication. tant. There are also additional products required to complete 

Another category of Messaging services. Specialized an environment such as additional networking software 
Messaging services, includes services that extend Core 65 which may be necessary for each individual client. In 
Messaging services to provide additional functionality. addition, development seat costs and production seat costs 

Implementation Considerations must considered. 
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Is synchronous or asynchronous communications 
required? 

All RFC products support synchronous program control. 
Some vendors are enhancing their products to provide 
asynchronous capabilities as well. Asynchronous means that 
while information is being passed via send and receive 
commands, programs can continue to process other tasks 
while waiting for a response to a request. 

What's the clients position on DCE? 

DCE software, developed by Open Systems Foundation 
(OSF), is licensed to OSF-member companies to form 
products that provide common services. The RFC is one of 
several DCE common services. Some clients naay desire to 
be aligned with DCE-based solutions. 

Is the middleware compatible with the other technology 
architecture components? 

Communications middleware products must integrate 
with other technology architecture components, develop- 
ment tools, and operations tools. Therefore, it is necessary to 
understand the compatibility between these tools and the 
communications middleware product. 

Is it important for the product to support multiple plat- 
forms and operating systems? 

The middleware products must support the required com- 
puting platform such as Wndows, UNIX, and Mainframe. It 
is common for vendors to claim that their product supports 
various platforms and operating systems, when in reality, 
that platform and operating system may be supported in a 
future release. It is important to request references of imple- 
mentations of the platforms and operating systems that are 
important to your specific envirorunent. 

What is the client's vendor direction? 

When evaluating a middleware product, its important to 
consider the clients relationships with vendors in the tech- 
nology market. For example, if the client has a strong 
relationship with a vendor ^o is also in the middleware 
market, it would be wise to investigate and consider such a 
vendor for the clients middleware solution. 

Is it important for the product to support multiple network 
protocols? 

The middleware products must support the network pro- 
tocols such as TCP/IP, LU6.2, and IPX/SPX that are impor- 
tant to your specific environment. It is important to note that 
protocols can vary across platforms. Ensure that the clients 
specific transport protocol version is supported by the com- 
munications middleware product. For example, communi- 
cations middleware vendors may support TCP/IP but they 
may not support the particular TCP/IP vendor that the client 
has selected. 

Is a quick response time critical? 

RPC performance may vary between products based upon 
the internal mechanisms and techniques of the product. For 
example, slow performance may be due to the processing 
overhead associated with each RPC call. Some RPC prod- 
ucts may improve performance by utilizing i^cial tech- 
niques used to invoke the server every time a client request 
arrives. Performance should be considered as a product 
differentiator. 

What level of security is required? 

There are potential security issues associated with the 
execution of commands on a remote system. Some vendors 
install security features into their products. It is also possible 
for the architecture team to build additional security into the 
overall solution. 

Is yclienl interested in a stable or emerging product? 

Vendors should be evaluated on the quality of service they 
offer, their market share, the age of their product, the 
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installed base of their product, and their financial stability. In 
addition, since this market is still emerging, there are many 
small vendors in the market trying to offer solutions. Vendor 
and product stabiUty should be taken very seriously. 
File Transfer 1530 

File Transfer services enable the sending and receiving of 
files or other large blocks of data between two resources. In 
addition to basic file transport, features for security, guar- 
anteed delivery, sending and tracking sets of files, and error 
logging may be needed if a more robust file transfer archi- 
tecture is required. The following are examples of File 
Transfer standards: 

File Transfer Protocol (FTP) allows users to upload and 
download files across the network. FTP also provides a 
mechanism to obtain filename, directory name, 
attributes and file size information. Remote file access 
protocols, such as Network File System (NFS) also use 
a block transfer method, but are optimized for online 
read/write paging of a file. 

HyperText Transfer Protocol (HTTP)— Within a Web- 
based environment, Web servers transfer HTML pages 
to clients using HTTP HTTP can be thought of as a 
lightweight file transfer protocol optimized for trans- 
ferring small files. HTTP reduces the inefSciencies of 
the FTP protocol. HTTP runs on top of TCP/IP and was 
developed specifically for the transmission of hypertext 
between client and server. The HTTP standard is 
changing rapidly. 

Secure Hypertext Transfer Protocol (S-HTTP) — a secure 
form of HTTP, mostly for financial transactions on the 
Web. S-HTTP has gained a small level of acceptance 
among merchants selling products on the Internet as a 
way to conduct financial transactions (using credit card 
numbers, passing sensitive information) without the 
risk of unauthorized people intercepting this informa- 
tion. S-HTTP incorporates various cryptographic mes- 
sage formats such as DSA and RSA standards into both 
the Web client and the Web server. 

File Transfer and Access Management (FTAM) — ^The 
OSI (Open Systems Interconnection) standard for file 
transfer, file access, and file management across plat- 
forms. 

Implementation Considerations 

Additional options for File Transfer Services in a homo- 
geneous environment could include the native operating 
systems copy utility, i.e. Wndows NT Copy features. 
Possible Product Options 

Computer Associates CA-XCOM; RemoteWaie; Hewlett- 
Packards HP FDVM; IBMs Files On-Demand gateway 
The following are examples of File Transfer products: 
Computer Associates CA-XCOM; RemoteWare; Hewlett- 
Packards HP FTAM; IBMs Files On-Demand gateway 
The following are examples of File Transfer products: 
Computer Associates' CA-XCOM — ^provides data trans- 
port between mainframes, midrange, UNIX, and PC 
systems. XcelleNet's RemoteWare — retrieves, 
appends, copies, sends, deletes, and renames files 
between remote users aixl enterprise systems. Hewlett- 
Packard's HP FTAM — provides file transfer, access, 
and management of files in OSI networks. 
The following product provides File Transfer translation: 
IBM's Files On-Demand gateway — ^acts as a gateway 
between Web-based and mainframe-based FTP ser- 
vices to allow users to download mainframe-based files 
from a World Wide Web browser. 
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RPC 1532 

RPCs (Remote Procedure Calls) are a type of protocol by 
which an application sends a request to a remote system to 
execute a designated procedure using the supplied argu- 
ments and return the result. RPCs emulate the function call 
mechanisms found in procedural languages (e.g., the C 
language). This means that control is passed from the main 
logic of a program to the called function, with control 
returning to the main program once the called function 
completes its task. Because RPCs perform this mechanism 
across the network, they pass some element of control from 
one process to another, for example, from the client to the 
server. Since the client is dependent on the response from the 
server, it is normally blocked from performing any addi- 
tional processing until a response is received. This type of 
synchronous data exchange is also referred to as blocking 
communications. 
Possible Product Options 

Sun Microsystems ONC+; OpenGroups DCE RPC; Novells 
NetWare RPC; NobleNet's EZ^RPC; Transarcs DCE 
RPC; Microsofts Windows95/NT RPC 
Sun Microsystems' ONC (Open Network Computing) 
OpenGroup's DCE (Distributed Computing 
Environment) 

Novell's NetWare RPC NobleNet EZ^RPC Transarc's 
DCE 

Microsoft's Windows95/NT RPC 
Message Oriented 1534 

Message-Oriented Middleware (MOM) refers to the pro- 
cess of distributing data and control throughout the 
exchange of records known as messages. MOM provides the 
application developer with a set of simple verbs (e.g., 
cormect, send, receive, and disconnect) that are used to 
exchange information with other distributed applications. 

Message-Oriented Middleware is responsible for manag- 
ing the interface to the underlying communications archi- 
tecture via the communications protocol APIs and ensuring 
the delivery of the information to the remote process. This 
interface provide the following capabilities: 

Translating mnemonic or logical process names to oper- 
ating system compatible format 

Opening a communications session and negotiating 
parameters for the session 

Translating data to the proper format 

Transferring data and control messages during the session 

Recovering any information if errors occur during trans- 
mission 

Passing results information and status to the application. 

An application continues processing after executing a 
MOM request, allowing the reply to arrive at a subsequent 
time. Thus, unlike RPCs, MOM implements a "non- 
bloddng** or asynchronous messaging architecture. 

Message-Oriented Middleware products typically support 
communication among various computing platforms (e.g., 
DOS, Windows, OS/2, Macintosh, UNDC, and mainframes). 

There are three types of Message-Oriented Middleware 
commonly implemented: 

Message Passing 

Message Queuing 

Publish and Subscribe 

Message Passing — as illustrated in FIG. 17, is a direct, 
application-to-application communication model. An appli- 
cation request is sent in the form of message from one 
application to another. The communication method can be 
either synchronous like RPCs or asynchronous (through 
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callback routines). In a message-passing model, a direct link 
between two applications that participate in the message 
exchange is always maintained. 

Message Queuing (also known as Store and Forward) — as 
depicted in FIG. 18, is an indirect application to application 
communication model that allows applications to commu- 
nicate via message queues, rather than by calling each other 
directly. Message queuing is asynchronous by nature and 
connectionless, meaning that the recipient need not be 
directly available when the message is sent. Moreover, it 
implies support for reliable, guaranteed and assured (non- 
duplicate) message delivery. 

Publish and Subscribe (also known as Push messaging) — 
as shown in FIG. 19, is a special type of data delivery 
mechanic that allows processes to register an interest in 
(i.e., subscribe to) certain messages or events. An applica- 
tion then sends Q)ublishes) a message, which is then for- 
warded to all processes that subscribe to it. 
Implementation Considerations 

When trying to decide whether to use MOM technology, 
keep the following characteristics of this type of middleware 
in mind: 

MOMs are high speed, generally connectionless and are 
usually deployed for executing applications with a 
nonblockdng sender 

MOM solutions are especially useful for inter-appHcation 
communication and are increasingly popular for inter- 
enterprise work 

MOMs support end-to-end business applications and pro- 
cess inter-operability 

MOMs are designed for heavily used production appli- 
cations and are generally capable of high throu^iput 
rates and fast transfer times. Data is usually fonvarded 
immediately, although it is possible to store it for later 
processing 
Possible Product Options 

PeerLogics PIPES; IBM MQSeries; BEAs MessageQ; 
Momentum XIPC; Microsoft MQ (Falcon); TibCo's Ren- 
dezvous 

Message Passing 
PeerLogic's PIPES 

PIPES Platform applications communicate through a 
messaging interface that allows asynchronous, non- 
blocking communications. The messaging model is 
well-suited to complex multi-tier applications because 
it inherently supports asynchronous, event-driven com- 
munications. 

Message Queuing 

IBM*s MQSeries 

New features found in version 5 include: 

A new Internet gateway that allows customers and part- 
ner to run mission critical business applications over an 
unreliable network. 

Enhanced message distribution carries more business 
information, while minimizing use of networks. 

Performance improvements gives message transmission 
at least 8 times faster than previous versions 

Resource Coordination ensures that data held in databases 
is always updated completely— or not at all, if processing 
cannot complete. 

Additional developer features include further language 
support for C++, Java and PL/1, and interoperabihty with 
current and previous MQSeries versions. 

Easier implementation because MQSeries now has the 
same install and use characteristics as other IBM Software 
Servers. 
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BEA's MessageQ 

Key highlights of the MessageQ product include: 

High performance — ^up to thousands of non-recoverable 
messages/second; himdreds of recoverable messages/second 

Both synchronous, and asynchronous message delivery 

Broadest platform support in the industry including 
UNIX, Windows NT, Open VMS, and mainframes 

Common implication Programming Interface (API) 

Publish and subscribe (broadcasting) 

Microsoft Windows client product with support for DLLs 
(Dynamically Linked libraries), \^ual Basic, and Power 
Builder development environments 

Message recovery on all BEA MessageQ clients and 
servers 

Interoperability with IBM MVS/QCS and IBM MVS/ 
IMS 

Large message size — ^up to 4 MB— eliminates need for 
message partitioning 
Momentum's XIPC 

XIPC is an advanced software toolset for the development 
of multitasking and distributed applications. XIPC pro- 
vides fault-tolerant management of guaranteed delivery 
and real-time message queuing, synchronization sema- 
phores and shared memory, all of which are network- 
transparent. 

Microsoft Message Queue Server (MSMQ, formerly known 
as Falcon) 

Publish and Subscribe 

TibCo's Rendezvous 

TIB/Rendezvous' publish/subscribe technology is the 
foundation of TIBnet, TibCos solution for providing 
information delivery over intranets, extranets and the 
Internet. It is built upon The Information Bus® fTIB®) 
software, a highly scaleable messaging middleware 
technology based on an event-driven publish/subscribe 
model for information distribution. Developed and 
patented by TIBCO, the event-driven, publish/ 
subscribe strategy allows content to be distributed on 
an event basis as it becomes available. Subscribers 
receive content according to topics of interest that are 
specified once by the subscriber, instead of repeated 
requests for updates. Using IP Multicast, TIBnet does 
not clog networks, but instead, provides for the most 
efiGcient real-time information delivery possible. 
Streaming 1536 

Streaming is the process of transferring time-sensitive 
data streams (e.g., video and/or audio) in real-time. Stream- 
ing differs from the other types of Core Messaging services 
in that it delivers a continuous, one-way stream of data, 
rather than the relatively short messages associated with 
RPC and Message-Oriented Middleware messaging or the 
large, batch transfers associated with File Transfer. (While 
the media stream is one-way from the server to the client, the 
cUent can issue stream controls to the server.) Streaming 
may be used to deliver video, audio, and/or other real-time 
content across the Internet or within enterprise networks. 

Streaming is an emerging technology. While some mul- 
timedia products use proprietary streaming mechanisms, 
other products incorporate standards. The following are 
examples of emerging standards for streaming protocols. 
Data streams are delivered using several protocols that are 
layered to assemble the necessary fimctionality. 
Real-time Streaming Protocol (RTSP)— RTSP is a draft 
Internet protocol for establishing and controlling 65 
on-demand delivery of real-time data. For example, 
clients can use RTSP to request ^)ecific media from a 
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media server, to issue commands such as play, record 
and pause, and to control media delivery speed. Since 
RTSP simply controls media delivery, it is layered on 
top of other protocols, such as the following. 

Real-Time Transport Protocol (RTP>— Actual delivery of 
streaming data occurs through real-time protocols such 
as RTP. RTP provides end-to-end data delivery for 
applications transmitting real-time data over multicast 
or unicast network services. RTP conveys encoding, 
timing, and sequencing information to allow receivers 
to properly reconstruct the media stream. RTP is inde- 
pendent of the underlying transport service, but it is 
typically used with UDP. It may also be used with 
Multicast UDP, TCP/IP, or IP Multicast. 

Real-Time Control Protocol (RTCP)— RTP is augmented 
by the Real-Time Control Protocol. RTCP allows nodes 
to identify stream participants and communicate about 
the quaUty of data dehvery. 

The following table summarizes the protocol layering that 
siq)ports Streaming: 



25 functionality 



sample protocol 
options 



architecture service 



controlling media KTSP or prt^iietary 
delivery 

monitoring data stream KTCP or prqirietary 



end-to-end delivery 
of stream 
message transport 

packet forwarding/ 
internetworking 



KTP or proprietary 

UDP, Multicast UDP, 
TCP 

IP, IP Multicast 



Streaming Messaging 
service 

Streaming Messaging 
service 

Streaming Messaging 
service 

Message Transport 
service 

Packet Forwarding/ 
Internetworking service 
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FIG. 20 depicts Streaming, in which a real-time data 
stream is transferred. 
Possible Product OptionsOptions 

Netscape's Media Server; Progressive Networks Real 
Audio/V^deo; VXtremes WebTheater 
The following are examples of products that implement 
Streaming Messaging (based upon RTSP or other standards 
or proprietary approaches): 
Netscape's Media Server 

Progressive Networks' Real Mdeo VXtreme's WebThe- 
ater 

Specialized Messaging 1538 

Specialized Messaging services extend the Core Messag- 
ing services to provide additional functionality, including: 
Provides messaging among specialized systems by draw- 
ing upon basic messaging capabilities 
Defines specialized message layouts 
Defines specialized inter-system protocols 
Suggests ways in which messaging draws upon directory 
and security services in order to deliver a complete 
messaging environment 
An example of a specialized messaging service is Mail 
Messaging. Mail Messaging is a specialized implementation 
60 of store-and-forwarding MOM (message-oriented 
middleware) messaging, in that Mail Messaging defines 
specialized, mail-related message layouts and protocols that 
utilize store-and-forward messaging. 
E-Mail 1540 

E-Mail takes on a greater significance in the modem 
organization. The E-Mail system, providing it has sufScient 
integrity and stability, can fimction as a key channel through 
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which work objects move within, and between organizations Post.OfEce — one of the leading POP3/SMTP mail servers 

in the form of messages and electronic forms. An E-Mail for the Internet community as well as corporate intra- 

server stores and forwards E-Mail messages. Although some nets. This message transport agent is based entirely on 

products like Lotus Notes use proprietary protocols, the the open standards of the Internet, ensuring maximum 

foUowmg protocols used by E-Mail Services are based on 5 compatibility with other systems, 
open standards: 

X.40a-The X.400 message handling system standard ^"^"^^1*^° ^"^^^ 

defines a platform independent standard for store-and- ™_ 1° , ^ 

forward message transfers among mail servers. X.400 is . foUowmg arc major proprietary E-mail servers used 

often used as a backbone e-mail service, with gateways ^ ^"^e organizations today: 

providing intercoimection with end-user systems. Lotus Notes — ^platform-independent client/server mail 

SMTP — Simple Mail Transfer Protocol (SMTP) is a system. Notes Mail can support over 1,500 active users 

UNIX/Internet standard for transferring e-mail among serv- per server, offering Internet integration, distributed 

replication and synchronization. Lotus Notes also pro- 

MIME— MuUi-Purpose Internet Mail Extensions vides integrated document libraries, workflow, calen- 

(MIME) IS a protocol that enables Internet users to exchange 15 scheduling, and a cc:Man user interface 

. ^ . Microsofts Exchange Server— Exchange 4.0 provides a 

^^"^ ^^^'"^ ^^^^^ "^^^"'^ messaging andgroupwareplatform to sui^rtcoLoration 

"SSji^^.!^^ "^A ^""S^/^rv • • A ^'^"^^"^ °° Windows machines. Microsoft Exchange 5.0 

IMAP4 — Internet Message Access Protocol, Version 4 . n n r *i, 1 ¥ * * * 1 

aMAP4)aUows a client to a^ and manipulate electronic 20 X^'LfT fj^" '".J^^r'^^ 

mail meLges on a server. IMAP4 permits manipulation of ^^^l^'^ ^""'J^f ^'''j^^ "^"^"^ 

remote message folders, called "mailboxes", in a way that is receivmg, NNTP for newsgroups and discussion 

functionally equivalent to local mailboxes. IMAP4 also directory access, HTTP and HTML for 

provides the capability for an off-line client to acc^ via a web browser, and SSL for security, 

re-synchronize with the server, IMAP4 includes standards 25 following products are examples of e-mail systems: 

for message handling features that allow users to download Microsoft Mail 

message header information and then decide viiich e-mail Lotus cc:mail 

message contents to download. Qualcomm Eudora 

Implementation Considerations The following products provides e-mail system transla- 

A number of E-mail servers from vendors including HP 30 tion: 

and Netscape are bmlt around SMTP, andmost proprietary TenFour's TFS Univcisal E-Mail Gateway-links users 

SS:^-. °f Development Corp.'s cc:M^ and Notes. 

The Multipart Internet MaJ Extensions (MIME) st^- Novell Inc's GroupWise, Mi^ft Corp.'s Mail, Ma 

dard has gained acceptance as the Internet mechanism for ^ail, and SMTP e-mail to Microsoft Exchangr 

sendmg E-mail contammg vanous multimedia parts, such as 35 ttit j- i- . 

images, audio files, and movies. S/MIME, or secure MIME ^J?^Kt^''^^ I'''' converting 8-bit binary files into 

adds encryption and enables a secure mechanism for trans- 7"'''^ files for transmission via e-mail over the 

ferring files Internet (the Internet only supports seven bit characters 

Although currentiy POP3 is the popular Internet E-Mail ^ messages); UUencode and UUdecode utilities 

message handling protocol, recently the lesser known 40 on end nodes j^rform the conversion. 

IMAP4 protocol has been gaining in adoption among mail database Access 1542 

server and mail cUent software providers. IMAP was , Database Messagmg services (also known as Database 

designed to add features beyond POP that aUow users to Access Middleware) provide connectivity for cHents to 

store and archive messages and support mobile users that daUbases throughout the enterprise. Database mes- 

needtokeepmessagesonacentralserverasweUasontheir 45 ^^Poo I'asic inter-proccss messaging 

laptop. capabihties (e.g., RPCs) in order to support database oon- 

Organizations are looking to use vehicles like E-Mail and n^^vity. Database Messaging services typically provide 

the Internet to enable communications with customers and f application scemless access to mulitple data sources, 

trading partners. The least common denominator E-mail ^""^^ relational and non-relational. Additionally, database 

capability today is very rudimentary (ASCn text). But as the 50 "^^^^S services can be used to facilitate migration of 

standardsUstedhereasweUasothersbecomeintegratedinto ^^f^^"". """^ environment to another (i.e., MVS/DB2- 

most of the popular E-mail products and gateways this will -*a^ase) 

change enabhng a more flexible and useful commercial ^^"^ ^ ^^^^ °^ database access middleware: 

communications medium. ODBC-like 

Possible Product OptionsOptions 55 Propietary 

Microsoft Exchange Server; Lotus ccrmail; Lotus Notes; Gateway 

Qualcomm Eudora; TenFours TFS Universal E-Mail is there a projected growth in data requirements? 

Gateway; UUcoding; Netscape Mail Server; Post.Offioe; Storage of data in a database allows for more optimal 

^"^'^^^^ fiiture growth since databases scale better than mechanisms 

The following E-Mail products are based on the open 60 such as flat files. 

Internet standards defined above: Should the data be secured and controlled? 

Netscape Mail Server-^etscapes implementation of an Use databases to protect data integrity from multiple user 

open standards-based client/server messaging system access, and hardware and software failures, 

that lets users exchange information within a company Is it desirable to linut the amount of viewed data? 

as well as across the Internet. It inchides support for all 65 Use databases to store large amounts of information and 

standard protocols, and is packaged with Nelscapes to access an individual record(s) without having to inspect 

SuiteSpot server line. all the records of a given topic. 
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Is tbere a need to impose data standards? 

Use a database when you wish to store and impose 
standards on data elements. This is important when devel- 
oping enterprise wide solutions, since it is desirable to have 
the different appUcations access the same structured infor- 
mation. 

Is there a current or potential requirement for a distributed 
architecture? 

Databases allow for the potential of such architectural 
features as a data replication strategy and/or distributed data 
access. 

Is there a need to minimize data duplication? 

Because of their normalized design, relational databases 
are used to reduce data redundancy. This reduces mainte- 
nance and storage requirements. 
Product Considerations 

What are the available administration or systems man- 
agement features? 

Administration and systems management features such as 
remote management, remote configuration, backup and 
recovery, and disaster recovery ^ould be considered. 

What are the key business requirements? 

Product selection may be influenced by business require- 
ments such as replication and distributed data, parallel 
processing, complex object support for such purposes as 
multimedia, OLTP, decision support, VLDB, data 
warehousing, and availability (24/7 vs. 8/5). 

What is the availability of market resources to support the 
product? 

Personnel available for support (permanent hires, 
contractors), and third party support for skilled resources/ 
training should be considered. 

Are the current data requirements expected to increase? 

Products differ in their ability to scale with respect to 
hardware architecture, transaction throughput, and user 
base. 

How do the vendors compare against one another? 

Issues to consider are type, quality and responsiveness of 
support, aUiances/partner^ips with other companies, mar- 
ket presence (install base, customer list, number of produc- 
tion copies, etc.), vendor industry, alignment of mission and 
vision with that of potential customer/evahiator, product 
philosophy, long-term product plans/strategy, and vendor's 
training. 

How well does a product integrate with the current or 
proposed architecture? 

Issues to consider include supported operating systems, 
networks, and other database platforms, availability of data- 
base utilities, application inter&ces, development tools, and 
third party products, and integration with legacy systems. 
Possible Product Options 

Oracles SQL* Net; Sybases Enterprise Connectivity; 

Microsoft's Open Database Connectivity (ODBC); Sun 

Java Database Connectivity (JDBC) 

Oracle's SQL*Net — supports database interoperability 
across a variety of transport protocols (e.g., TCP/IP, 
SPX/IPX, SNA, etc.); includes verbs such as cocmect, 
send, receive, and disconnect; performs transparent 
protocol bridging by allowing multiple protocols to 
reside simultaneously on eadi node. 

Sybase's EnterpriseConnectivity — supports database 
interoperability across a variety of platforms. 

Microsoft's Open Database Connectivity (ODBC) — a 
database programming interface that provides a com- 
mon language for Windows applications to access 
databases on a network. 

Sun's Java Database Connectivity (JDBC) — a Java-based 
programming interface that provide a conunou method 
for Java applications to access databases on a network. 
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Object Messaging 1544 

Object Messaging enables objects to transparently make 
requests of and receive responses from other objects located 
locally or remotely. Objects communicate through an Object 

5 Request Broker (ORB). An ORB enables client objects to 
access server objects either locally or remotely over a 
network and invoke operations (i.e. functions and methods) 
on them. ORBs typically provide interoperabihty between 
heterogeneous client and server envirormients: across lan- 

10 gu^gcs and/or operating systems and/or network protocols. 
In that re^>ect some have said that ORBs will become a kind 
of "ultimate middleware" for truly distributed processing. A 
standardized Interface Definition Language (IDL) defines 
the interfaces that applications must use to access the ORB 

15 Services. The two major Object Request Broker standards/ 
implementations are: 

Object Management Group's Common Object Request 

Broker Architecture (CORB A) 
Microsoft's (Distributed) Component Object Model 

20 (COM/DCOM) 
CORBA 

Conmion Object Request Broker Architecture (CORBA) 
is a standard for distributed objects being developed by the 
Object Management Group (OMG). The OMG is a consor- 

25 tiiun of software vendors and end users. Many OMG mem- 
ber companies are developing commercial products that 
support the CORBA standards and/or arc developing soft- 
ware that use these standards. CORBA provides the mecha- 
nism by which objects transparently make rcquests and 

30 receive responses, as defined by OMG's Object Request 
Broker (ORB). The CORBA ORB is an application frame- 
work that provides interoperability between objects, built in 
different languages, running on different machines in het- 
erogeneous distributed environments. 

35 Inter-ORB Messaging 

The OMGs Internet Inter-Orb Protocol (IIOP) specifies a 
set of message formats and common data representations for 
communication between ORBs over TCP/IP networks. 
CORBA-based Object Messaging is summarized in FIG. 21. 

40 COM/DCOM 

Component Object Model (COM) is a client/server 
object-based model, developed by Microsoft, designed to 
allow software components and applications to interact with 
each other in a uniform and standard way. The COM 

45 standard is partly a specification and partly an implementa- 
tion. The specification defines mechanisms for creation of 
objects and communication between dejects. This part of the 
specification is paper-based and is not dependent on any 
particular language or operating system. Any language can 

50 be used as long as the standard is incorporated. The imple- 
mentation part is the COM library which provides a number 
of services that support a mechanism which allows appli- 
cations to connect to each other as software objects. COM 
is not a software layer through which all conmiunications 

55 between objects occur. Instead, COM serves as a broker and 
name space keeper to cormect a client and an object, but 
once that connection is established, the chent and object 
commimicate directly without having the overhead of pass- 
ing through a central piece of API code. Originally oon- 

60 ceived of as a compound document architecture, COM has 
been evolved to a full object request broker including 
recendy added features for distributed object computing. 
DCOM (Distributed COM) contains features for extending 
the object model across the network using the DCE Remote 

65 Procedure Call (RPQ mechanian. In sum, COM defines 
how components should be built and how they should 
interact DCOM defines how they should be distributed. 
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Currently COM/DCOM is only supported on Windows- CTI ServerAVorkstation-based or Host-based API 

based machines. However, third-party vendors are in Products— operate on a particular computer vendor's 

pro^ss of porting this object model to other platforms such hardware platform and provide call control and mes- 

^ Macintosh, UNIX, etc. na 22 Illustrates COM Messag- saging functionality. 

Implementation Considerations ^ ^ Cross-Platfonn Vendors-Products that have been 

Although ORBs provide a mechanism for transparently ^^^^ multiple hardware platforms/operating sys- 

communicating among components located locally or tems. 

remotely, performance issues need to be thoroughly Enabling Solutions — focus solely on call control 

addressed before moving components around the network call/application synchronization functions. 

Making requests and receiving responses among compo- ^ Enterprise Solutionsr-^jrovide all CTI business 

nents located on different machines will take longer that functions to varying degrees, 

having the same communication between components Possible Product Options 

located on the same machine. Performance is dependent on Novell's Netware Telephony Services; Microsoft TAPI; 

what type of network is avaflable (LAN, type of LAN, Novell TSAPI 

WAN, type of WAN, dial-up, wireless, etc.), size of mes- Industry-Standard y^plication Programming Interfaces 

sages and number of messages that go across the network. (APIs): 

Possible Product Options Microsoft's TAPI 

Expersoft's CORBAplus; IBM's Component Broker; BEA- Novell's TSAPI 

Systems ObjectBroker; lona Technology's Orbix; ^ NoveU's Netware Telephony Services— Based on Nov- 

Inpnse's Visibroker, Microsofls COM; Software AGs ell's Telephony Services API (TSAPO, Netware 

Telephony Services is a CTI gateway that integrates 

CORBA-based ORB products Novell networiss with telephony networiss. 

Expersoft's CORB^lus Other vendors of CTI products include: 

IBM's Component Broker 25 Aspect Telecommunications Corp. 

BEA's Object Broker Genesys Labs 

lona Technologies's Orbix ^BM 

Inprise's A^iBroker(formerly \^genic) Lucent 

COM products 

Microsoft's DCOM (Wndows NT Server, Windows NT 30 

A^ikstati(Hi,\Wndows 95, Apple Macintosh, Windows RockweU 

Java Virtual Machine) ^"^ Messaging 1548 

Software AG's COM (cunent or planned availability on ™^ (Electronic Data Interchange) supports system-to- 

Sun, Digital UNIX, IBM, and HP platforms) system messagmg amoiig busmess partners by defining 

Cn Messaging 1546 35 standard message layouts. Companies typically use EDI to 

Computer-Telephone Integration (CTI) integrates com- commercial transactions within their supply 

puter systems and telephone systems to coordinate data and . j j/ nr.,T^A^ »v„.. . - 

telephony activities. For example. CH can be used to , ED^ standards (e.g.. EDIFACT. ANSI X12) define record 

associate a customers database entry with the customers ^''^'^^ for transactions such as -purchase orders". EDI 

telq)hone call and route the caU accordingly « generation and translation of EDI mes- 

Referring to FIG. 23. Cn Messaging supports commu- accordmg to the various pubUc message layout stan- 

nication among clients 2300, CTI servers 2382, PBXs/ ■ ... 

ACDs 2304, hybrid platforms, networks 2306, and external ™' messaging can be implemented via electronic mail or 

telephony devices. Cn Messaging relies upon proprietary "^"^<^ message-onented architectures. 

PBX/ACD APIs, Cnvendor^pecificAPIs or message sets^ « Impkmentation Considerations 

and industry-standard APIs EDI messages have traditionally been sent between com- 

Cn Messaging has two primary functions: 0^*^^ Added Network). VANs have 

Device-specific communication been cnticized for the^ relatively high cost in comparison to 

... ... , ^ , ^ pubhc networks like the Internet. RecenUy. EDI messaging 

dSJnTn tT"" 50 vendorssuchasPremenoshavebeencreatingsoftware^l 

devices and data devices built-in encryption features to enable compai^es to send EDI 

Allows applications to control PBXs, key telephone transmissions securely over the Internet 

systems, ISDN, analog PSTN, ceUular, Centrex, etc. Web server vendors including Microsoft, Netscape and 

and supports features such as address translation, caU OpenMarket are putting plans in place to add EDI transmis- 

senip, call answenng, caD droppmg, and caller ID. sion capabilities into their Web server products. OpenMaricet 

Provides mterfaoe to carrier networks for call deUvery and Inc. is working with Sterling and Premenos to integrate their 

caU-related messaging EDI management software with OpenMarkets OMTransact 

Message mapping electronic commerce server software. Netscape is working 

Translates device-specific communication to generic API with GEIS in creating Actra Business Systems to integrate 

and/or message set ^ EDI services with Netscape server products. 

cn products can be divided into the following categories: Possible Product Options 

cn Platform-Specific Products^roducts that can only I>igital Equipment Corp.s DEC/EDI; Sterling Commerces 

be implemented on the hardware of a ^)ecific vendor. GENTRAN; IBM Global Services Advantis; GE Infor- 

Cn Telephony-based API Products — include propri- mation Services; Sterling Commerce 

etaryPBX/ACD-based messaging sets, which permit 65 EDI Applications 

external devices to interface with the vendor's PBX/ Digital Equipment Corp.'s DEC/EDI 

ACD call and station control logic Sterling Commerce's GENTRAN 
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EDI value-added nelwories (VANs)— VANs link EDI 
trading partners and transmit EDI messages through a 
central electronic clearinghouse 

IBM Global Services' Advantis 

G£ Information Services 

Sterling Commerce 
Legacy Integration 1550 

Legacy services provide gatewarys to mainframe legacy 
systems. The following protocol is typically used: 

Systems Network Architecture (SNA) is a networking 
connection-oriented protocol architecture which was 
developed in the 1970s by IBM. Currently, SNA and 
TCP/IP are two of the most widely used networking 
protocol architectures. 

Design techniques for integration with existing systems 
can be grouped into two broad categories: 

Front end access — discussed as part of Terminal Emula- 
tion 

Back end access — tend to be used when existing data 
stores have information that is needed in the client/ 
server environment but accessing the information 
through existing screens or functions is not feasible. 
Legacy Integration messaging services typically 
include remote data access through gateways. A data- 
base gateway provides an interface between the client/ 
server environment and the legacy system. The gate- 
way provides an ability to access and manipulate the 
data in the legacy system. 
Implementation Cbnsiderations 

Legacy systems hold critical data which must be acces- 
sible by new Netcentric computing solutions. These legacy 
data sources often must be accessed in their current foraa so 
as to not disrupt the legacy systems. 
Communications Security 1508 

Communications Security services control access to 
networic-attached resources. Combining network Security 
services with security services in other parts of the system 
architecture (e.g., apphcation and database layers) results in 
robust security. 
Possible Product Options 
UkWeb's Stronghold; UkWeb's SafePassage 
UkWeb's Stronghold 

Stronghold was the first web server to support SSL Client 
Authentication. Regular expression-based matching of cli- 
ent certificate information to determine access control is 
possible. Stronghold also has an API for certificate to 
usemame mapping so that client certificates may be mapped 
to standard usemames. CA certificates from both Thawte 
and Verisign can be utilized. Uncompromised, full 128-bit 
symmetric encryption is provided in all versions. This 
provides Netcentric systems used outside of the USA or 
Canada with secure encryption capabilities. 
UkWebs's SafePassage 

SafePassage is a full -strength, encrypting Web proxy. It is 
designed to supplement the security of browsers whose 
authentication and encryption capabilities have been weak- 
ened to comply with United States export regulations. For 
these types of browsers, SafePassage will provide client 
authentication certificates and full-strength encryption (128 
bit). 

Encryption 1552 

Encryption services encrypt data prior to network transfer 
to prevent unauthorized interception. (Note that encryption 
can occur within the Communications Services layer, the 
Transport Services layer, or the Network Media Sendees 
layer.) Within the Commimications Services layer, encryp- 
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tion occurs at the top of the protocol stack and is typically 
performed within an ^plication (e.g., an e-mail application, 
a Web browser). This is an end-to-end approach that can 
leave the remainder of the protocol stack (i.e., the Transport 
services and the Network Media services) unaffected. 

Encryption has two main components: the encryption 
algorithm, which is the series of steps that is performed to 
transform the original data; and the key, which is used by the 
algorithm in some way to encrypt the message. Typically, 
the algorithm is widely known, while the key is kept secret. 
There are several types of encryption in use today, including: 
Secret key cryptography— uses one key (the secret key) 
both to encrypt the message on one side and to decrypt 
the message on the other side. 
Public key cryptography — uses two keys, the public key 
and the private key. The public key and private key are 
mathematically related so that a message encrypted 
with the recipient's public key may be decrypted with 
the recipient's private key. Therefore, the public key 
can be widely published, while the private key is kept 
secret. 

There are also varying methods of employing encryption 
types described above to encrypt data sent across a network: 
Data hnk layer — data is encrypted before it is placed on 

the wire. Data link encryptors are generally hardware 

products. 

implication layer — data is encrypted by the application. 

Netscape's Secure Sockets Layer (SSL) is one example 

of application-layer encryption for VWW browsers. 

SSL uses RSA encryption to wr^ security information 

around TCP/IP based protocols. 
Network layer — data is encrypted inside the network 

layer header, therefore relying on the network layer 

protocol. 
Implementation Considerations 

The advan tage o f SSL over S/HTTP is that SSL is not 
restricted to HTTP but can also be used for securing other 
TCP/IP based services such as FTP, Tehiet, etc. SSL can 
provide session level data encryption and authentication to 
enable secure data communications over public networks 
such as the Internet. 

The need for Encryption Services is particularly strong 
where electronic commerce solutions that involve exchang- 
ing sensitive or financial data are to be deployed over public 
networks such as the Internet. Cryptography can be used to 
achieve secure communications, even when the transmission 
media (for example, the Internet) is untrustworthy. Encryp- 
tion Services can also be used to encrypt data to be stored 
(e.g., sensitive product information on a sales person's 
laptop) to decrease the chance of information theft. 

There are complex legal issues surrounding the use of 
encrypting in an international environment. The US govern- 
ment restricts what can be exported (in terms of encryption 
technology), and the French government defines encryption 
technology as a "weapon of war" with appropriate legal and 
regulatory restrictions. This is a key issue in international 
e-commeroe today. 
Possible Product Options 

Netscape's Secure Sockets Layer (SSL); S-HTTP; e-mail 

encryption; S-MIME 
Encryption that is architected into Web-based solutions 
Netscape's Secure Sockets Layer (SSL) — provides 

encryption for World Wide Web browsers. 
S-HTTP — a secure version of the HTTP data transfer 
standard; used in conjunction with the World Wide 
Web. 
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EDcryptioa that is embedded in e-mail products 
e-mail encryption — products such as Lotus Notes and 
Microsoft Exchange can encrypt e-mail messages and/ 
or attachments. 
S-MIME — a secure version of the MIME e-mail standard. 
Authorization 1554 

When a user requests access to network resources, the 
Authorization service determines if the user has the appro- 
priate permissions and either allows or disallows the access. 
(This occurs after the user has been properly authenticated.) 

The following are examples of ways to implement Autho- 
rization services: 

Network Operating Systems — Authorization services are 
bundled with all network operating systems in order to 
control user access to network resources. 
Firewall Services protect sensitive resources and infor- 
mation attached to an Intxxnet network from unautho- 
rized access by enforcing an access control policy. A 
variety of aiechanisms exist for protecting private 
networks including: 

Filters — World Wide Web filters can prevent users from 
accessing specified content or Internet addresses. 
Products can limit access based on keywords, net- 
work addresses, time-of-day, user categories, etc. 

v^>plication Proxies — ^An application-level proxy, or 
application-level gateway, is a robust type of fire- 
wall. (A firewall is a system that enforces an access 
control policy between a trusted internal network and 
an untrusted external network.) TTie application 
proxy acts at the application level, rather than the 
network level. The proxy acts as a go-between for 
the end-user by completing the user-requested tasks 
on its own and then transferring the information to 
the user. The proxy manages a database of allowed 
user actions^ whidi it checks prior to performing the 
request 

Servers, y^plications, and Databases — ^Authorization can 
occur locally on a server to limit access to specific 
system resources or files. .^>plications and databases 
can also authorize users for !^)ecific levels of access 
within their control. (This functionality is within the 
Environment Services grouping in the execution 
architecture.) 
Possible Product Options 

Microsoft Windows NT; Novell Netware; UNIX; Check 
Points Firewall- 1; Raptor Systems Eagle Firewall; 
Microsoft Proxy Server; Netscape Proxy Server; Micro- 
system Softwares Cyber Patrol Corporate; Net Nanny 
Softwares Net Nanny 
Network Operating Systems 

Microsoft Windows NT, Novell Netware, UNIX, etc. 
.^>plication Proxies 

Microsoft Proxy Server— allows for designation of who 
can access the Internet and whid] services they can use. 
Administrators can establish additional credentials for 
logging on, set specific dialing hours or days of the 
week, and restrict access to certain sites altogether. 
Netscape Proxy Server — high-performance server soft- 
ware for replicating and filtering access to Web content 
on the Internet or an intranet. Provides access control, 
URL filtering, and virus scanning. 
Filters 

Check Point FireWall-1 — combines Internet, intranet and 
remote user access control with strong authentication, 
encryption and network address translation (NAT) ser- 
vices. The product is transparent to network users and 
supports multiple protocols. 
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BorderWare Firewall^rotects TCP/IP networks from 
imwanted external access as well as provides control of 
internal access to external services; supports packet 
filters and application-level proxies. 

Raptor System's Eagle Firewall 

Microsystem Software's Cyber Patrol Corporate 

Net Nanny Software's Net Nanny 
Authentication 

Authentication services verify network access requests by 
validating that users are who liey claim to be. For secure 
systems, one or more authentication mechanisms can be 
used to validate authorized users and to verify which func- 
tions and data they have access to. Within the corporate 
network, authentication services are often included in direc- 
tory services products like Novell's NDS. NDS requires the 
user to have an established account and supply a password 
before access is granted to resources through the directory. 

Authentication for accessing resources across an Internet 
or intranet is not as simple and is a rapidly evolving area. 
When building e-commerce Web sites there may be a need 
to restrict access to areas of information and functionality to 
known customers or trading partners. More granular authen- 
tication is required where sensitive individual customer 
account information must be protected firom other custom- 
ers. 

Authentication can occur through various means: 
Basic Authentication — requires that the Web client supply 
a user name and password before servicing a request. 
Basic Authentication does not encrypt the password in 
any way, and thus the password travels in the clear over 
the network where it could be detected with a network 
sniffer program or device. Basic authentication is not 
secure enough for banking applications or anywhere 
where there may be a finaixnal incentive for someone 
to steal someone's account information. Basic authen- 
tication is however the easiest mechaiusm to setup and 
administer and requires no special software at the Web 
client. 

ID/Password Encryption — offers a somewhat higher level 
of security by requiring that the user name and pass- 
word be encrypted during transit. The user name and 
password are transmitted as a scrambled message as 
part of each request because there is no persistent 
connection open between the Web client and the Web 
server. 

Digital Certificates or Signatures — encrypted digital keys 
that are issued by a third party "trusted" organization 
(i.e. Verisign); used to verify user's authenticity. 
Hardware tokens — small physical devices that may gen- 
erate a one-time password or that may be inserted into 
a card reader for authentication purposes. 
Wtual tokens — typically a file on a floppy or hard drive 

used for authentication (e.g. Lotus Notes ID file). 
Biometric identification — the analysis of biological char- 
acteristics to verify individuals identify (e.g., 
fingerprints, voice recognition, retinal scans). 
Related to authentication, non-repudiation is a means of 
tagging a message in order to prevent an entity ft^om denying 
that it sent or received the message. 
Possible Product Options 

Microsoft Windows NT; Novell NetWare; UNIX; Platinum 
Technologies AutoSecure SSO; Axents Enterprise Access 
Control for Windows 95; SecurlD; Racals TrustMe 
Authentication Server; Agonies Facelt; Sensars Irisldent; 
Keyware Technologies \foice Guardian; National Regis- 
trys NRIdentity; Kerberos; VeriSign 
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The following are examples of products that perfonn An intelligent network adds value to enterprise resources 

authentication: by presenting a cohesive view of available resources 

user IDs and passwords increasing the level of security associated with 

operating systems: Microsoft Windows NT, NoveU 171^°^ resources. , ^ ^ ^ 

NetWare UNIX etc ^ illustrates vanous components of the Commum- 

' * cation Fabric, 

apphcation level user IDs and passwords (e.g., e-mail Transport Services 2402 

system) Provides the underlying protocols responsible for trans- 

smgle sign-on softwar^manages user logins to multiple fitting and securing data communications. Transport Ser- 

systenis or resources. responsible for establishing, maintaining and ter- 

Platinum Technologies' AutoSecure SSO minating end-to-end communications between users and 

add-on administration packages — enhance the capabilities processes. Connection management provides transfer ser- 

of native operating system security, vices that ensure the delivery of data from sender to receiver, 

Axent's Enterprise Access Control for Windows which support the transferring of messages from a process 
95 — enforces password standards and encrypts data. 15 running on one machine to a process nmning on another 

Hardware Tokens machine. In addition, coimection management provides ser- 

Security Dynamics* SecurlD Authentication Tokens initiate a connection, gracefully terminate a 

Racal's TnistMe Authentication Server connection, and handle abnipt termination^ These services 

Biometric Security ^ W^ication before and after the data is 
. 20 formatted for transport over the network. 

Visionics Facelt— face recognition Messaging Transport 2404 

Sensar's hisldent— iris identification The Message Transport service is responsible for the 

Keywarc Technologies' Voice Guardian — voice reoogni- end-to-end delivery of messages. It can include the follow- 

tion ing functionality: 
National Registry's NRIdentity — fingerprint recognition 25 End-to-End Data Transfer — The Message Transport Ser- 

Keys and Certificates vice formats messages for sending and confirms the 

Kerberos— an encryption and key management protocol integrity of received messages. 

for third party authorization; vendors include Cyber- Connection Control — The Message Transport service 
SAFE and Digital Equipment Corporation. naay establish end-to-end (client-server) connections 
Verisign— a company that manages digital certificates. ^ ^^^^ addresses and other associated information 
Communication Fabric 1010 connection. The service also tears down con- 
As communication networks become increasingly com- nections and handles hard connection faQures. 
plicated and interconnected, the servioes provided by the Reliable Transfer — The Message Transport service may 
network itself have by necessity increased as well. Clients manage reliable delivery of messages through the use 
and servers are rarely directly connected to one another, but acknowledgments and retran^nissions. 
separated by a network of routers, servers and firewalls Flow Control — ^The Message Transport service may allow 
providing an ever increasing number of network services the receiver to govern the rate at ^ch the sender 
such as address resolution, message routing, security screen- transfers data. 

ing and many more. Multiplexing — ^The Message Transport service may 

The communications fabric provides common network ^ define multiple addresses or ports within a single 

services to the platform-specific network services residing network node, allowing multiple processes on the node 

on the client and server nodes. These common network to have their own communications paths, 

servioes can be used to manage resources and translate (Some transport services do not implement all of the listed 

capabilities within and across enterprises. functionality. For example, the UDP protocol does not offer 

Short of interpreting the data being transmitted, the com- connection control or reliable transfer.) 

munications fabric is aware of the different message- The following are examples of protocols that provide 

oriented information streams in order to help the client and message transport: 

server communicate regardless of the different network SPX (Sequenced Packet exchange) 

functions implemented on each platform. TCP (Transmission Control Protocol) 

An intelligent communications fabric monitors and routes ujjp (User Datagram Protocol) 

data flows and provides fimrtionality (sec^^ NetBIOS/NetBEUI (Network Basic Input/Output 

etc.) to chente and servers. AnmteUigent communications System/NetBIOS Extended User Interface) 

fabnc provides the foUowmg benefits: Aiinr-/A^ . t> ^ . . x 

, ^ u tr • 1 J. APPC (Advanced Program-to-Program Communications) 

An mtelligent network can manage itself, mcludmg AppleTalk 

addressing routing, secority recovery elc. It is ineffi- p^^^^^ Forwaiding/Intemetworking 2406 

^forindtvidualcheDtsandservetstoperformsuch Packet For^arding/Intemettorking service transfers 

, , data packets and manages the path that data takes through 

Specialized network components reduce the network- the network. It includes the foUowing functionaUty: 

related processing that occms on chents and servers. ^ Fragmentation/Reassembly-The Packet Forwarding/ 

An mteUigent network mtegrates heterogeneous clients, Intemetworidng service divides an application message 

servers, and other resources by resolving incompatible into multiple packets of a size suitable for network 

protocols and standards. transmission. The individual packets include informa- 

An intelligent network has the capability to actively tion to allow the receiving node to reassemble them 

manage the flow of information rather than simply 65 into the message. The service also validates the integ- 

moying data. This allows the network to effectively rity of received packets and buffers, reorders, and 

deliver multimedia and other network-sensitive traffic. reassembles packets into a complete message. 
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Addressing — ^The Packet Forwarding/Interaetworking Cisoos Interior Gateway Routing Protocol (IGRP) and 

service enc^sulates packets with addressing informa- Enhanced IGRP 

Link-State Protocols — each router periodically broad- 
Routing — ^The Packet Forwarding/Internetworking ser- casts changes to the routers and directly attached net- 
vice can maintain routing information (a view of the 5 works that it can talk with, 
network topology) that is used to determine the best Open Shortest Path First (OSPF) 
route for each packet. Routing decisions are made ISOs Intermediate System to Intermediate System 
based on the cost, percent utilization, delay, reliability, (IS — IS) 

and similar factors for each possible route through the NoveUs NetWare link Services Protocol (NLSP) 
network. lo Policy Routing Protocols — allow Internet backbone rout- 
Switching — Switching is the process of receiving a ers to accept routing information bom neighboring 
packet, selecting an appropriate outgoing path, and backbone providers on the basis of contracts or other 
sending the packet. Switching is performed by routers non-technical criteria; routing algorithms are Distance 
and switches within the communications fabric. Vector. 

Switching can be implemented in the following ways: Border Gateway Protocol (BGR) 

For some network protocols (e.g., IP), routers draw Interdomain Routing Protocol (IDR) 

upon dynamic routing information to switch packets Circuit Switching 2408 

to the appropriate path. This capability is especially While Message Transport services and Packet 

important when connecting independent networks or Forwarding/Internetworking services support the transfer of 
subnets. 20 packetized data. Circuit Switching services establish physi- 

For other network protocols (e.g., Ethernet, Token cal circuits for the transfer of circuit-switched voice, fax. 

Ring), switching simply directs packets according to video, etc. 

a table of physical addresses. The switch can build Circuit Switching 

the table by "listening" to network trafiBc and deter- uses an end-to-end physical connection between the 

mining which network nodes are connected to which ^ sender and the receiver that lasts for the duration of the 

switch port. "call" 

Some protocols such as Frame Relay involve defining u^Mcs voice, video, fax, etc. 

permanent routes (permanent virtual circuits PVCs) * i j a * ■ * •* -* i_ j * ^ 

-*t.* *u * 1 c- r n 1 • L J mcludes data m a circuit switched architecture (e.g., 

witmn the network. Smoe Frame Relay is switdied ^ connectio ^ ^ & ' 

based upon PVCIs, routing functionality is not ^ Packetized^ conne ons; 

XM _j-/T* *„_i* transferred through brief, temporary, logical connections 

Multicastmg-Tlie Packe Forwaidm^temetwoikmg ^^^^ ^^^^^^ datVand paXtized multime- 

service may support multicastmg, which is the process ^ . 

of transferrmg a single message to multiple recipients Circuit Switching includes the following functionality: 

at the same Ume. Multicastmg allows a sender to * li- . j 7 . . - ^ . / , 

transfer a single copy of the messagp to the conununi- estabtetes end-to-end path for circuit (may nivolved 

cations fabii^whi^h then distribmes the message to ""^"P'*' mtermediate nodes/switches) 

multiple recipients. manages end-to-end path (quality, bflling, termination. 

The following are examples of protocols that provide . „ . 
Packet Forwarding/Intemetworldng: *° ^® foUowmg are examples of Circuit Switching: 

IP (Internet Protocol) analog dial-up telephone circuit 

IP Multicast (emerging standarf that uses a special range „ S^^*'?!?''^'** 

f ra * • . -1 * . J 1- Possible Product Options 

of IP addresses to instruct network routers to dehver , c -4. ir _* i -j- t . t^^^ *t 

u 1 ♦ ♦ n • 1 J • . . X Lucent s Defimty; Nortels Mendian; Lucents E5S; Nortels 

each packet to all users mvolved in a multicast session) j^^^^ 'rn u/V* n_ ^ t * ^J^^ T 

iTiv /T r 1 n 1 ^ 1- X DMS; Tellabs Titan Products; Lucents DSX Products; 

IPX (Internetwork Packet Exchange) j^^^^ 3X Products; AltiGens AltiServ; Lucents Internet 

ATM (Asynchronous Transfer Mode) Telephony Server 

Frame Relay The following are examples of PBX products, which 

X.25 perform circuit switching within private telephone net- 

SMDS (Switched Multimegabit Data Service) ^^^s: 

The following are examples of network components that Lucent's Definity 

perform Packet Forwarding/Intemetworking: Nortel's Meridian 

routers Th^ following are examples of central oflSce (telephone 

s^^tches company) switches, which perform circuit switching within 

ATM switches. Frame Relay switches, IP switches, Eth- P"*'"'; 

emet switches. Token Ring switches, etc. Lucent's ESS 

The following are examples of protocols that maintain Nortel's DMS 

routing information tables within routers: The following are examples of Digital Access Cross- 
Distance Vector Protocols^ach router periodicaUy 60 connect Systems (DACS), which are configured to switch 

informs neighboring routers as to the contents of rout- circuits among multiple ports. 

ing table (destination addresses and routing metrics); Tellabs' Titan products 

routing decisions based on the total distance and other Lucent's DSX products 

"costs" for each path. Alcatel's SX products 

IP and IPX Routing Information Protocols (RIP) 65 The following is an example of a PC-based PBX system: 

AppleTalk Routing Table Management Protocol AltiGen's AltiServ— PC-based PBX system for a small 

(RTMP) branch office or a low-volume specialized call center. 
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The following is an example of a circuit-switching/ 
packet-forwarding gateway: 

Lucent's Internet Telephony Server — server software that 
routes calls from PBXs over the Internet or intranets. 
Transport Security 2410 

Transport Security services (within the Transport Services 
layer) perform encryption and filtering. 
Transport-layer Encryption 

Encryption within the Tran^rt Services layer is per- 
formed by encrypting the packets generated by higher level 
services (e.g., Message Transport) and encapsulating them 
in lower level packets (e.g.. Packet Forwarding/ 
Internetworking). (Note that encryption can also occur 
within the Communications Services layer or the Network 
Media layer.) Encryption within the Transport Services layer 
has the advantage of being independent of both the appli- 
cation and the transmission media, but it may make network 
monitoring and troubleshooting activities more difficult. 

The following standards support transport-layer encryp- 
tion: 

Point to Point Tuimeling Protocol 
Layer 2 Tbnneling Protocol 
Transport-layer Filtering 

Network traffic can be controlled at the Transport Services 
layer by filtering data packets based on source and/or 
destination addresses and network service. This ensures that 
only authorized data transfers can occur. This filtering is one 
of the roles of a packet filtering firewall. (A firewall is a 
system that enforces an access control policy between a 
trusted internal network and an untrusted external network.) 

The following IETF standard supports interoperability 
among security systems: 

IPSec Allows two nodes to dynamically agree on a 
security association based on keys, enoyption, authen- 
tication algorithms, and other parameters for the con- 
nection before any communications take place; oper- 
ates in the IP layer and supports TCP or UDP. IPSec 
will be included as part of IPng, or the next generation 
of IP. 

Implementation Considerations 

Firewalls can also provide a single point of access to the 
companys network, which could be used to maintain an 
audit trail. Some firewalls provide summaries to the admin- 
istrator about the type of traffic and amotmt of traffic passed 
through it, number of break in attempts, etc. 

Most commercial firewaUs are configured to reject all 
network traffic that has not been explicitly allowed, thus 
enforcing the policy. Only allow traffic that has been cat- 
egorically permitted, otherwise prohibit. This pohcy pro- 
vides much more control and is much safer than a policy 
which allows traffic unless it has been explicitly prohibited. 
Possible Product Options 

Cisco Systems; Bay Networks; 3Com Corp.; Check Points 
Firewall-l; Raptor Systems Eagle FirewaU; Data Fellows 
F-Secure VPN; Racals Datacryptor 64F 
The following are examples of vendors of products that 
perform Transport-level encryption: 
routers: 

Cisco Systems 

Bay Networks 

3Com Corp. 
firewalls: 

Check Point's Firewall-l 

Secure Computing's BorderWare Firewall Server 
Raptor Systems' Eagle Firewall 
encryption devices: 
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Data Fellows' F-Secure VPN 

Racal's Datacryptor 64F 
The following are examples of products that perform 
Transport-level packet filtering: 
firewalls: 

Check Point FireWall-l — combines Internet, intranet 
and remote user access control with strong 
authentication, encryption and network address 
translation (NAT) services. The product is transpar- 
ent to network users and supports multiple protocols. 
Secure Computing's BorderWare Firewall Server pro- 
tects TCP/IP networks from unwanted external 
access as well as provides control of internal access 
to external services; supports packet filters and 
application-level proxies. 
Raptor Systems* Eagle Firewall 
routers: 

Cisco Systems 
Bay Networks 
3Com Corp. 
Network Address Allocation 2412 

Network Address Allocation services manage the distri- 
bution of addresses to network nodes. This provides more 
flexibihty compared to having all nodes assigned static 
addresses. This service assigns addresses to nodes when they 
initially power-on and connect to the network. 

The following are examples of standards that implement 
Network Address Allocation and allow a network node to 
ask a central resource for the node_s network address (e.g., 
IP address): 

DHCP (Dynamic Host Configuration Protocol) 

BootP bootstrap Protocol) 
Quality of Service 2414 

Different types of network traffic (e.g., data, voice, video) 
have different quality of service requirements. For example, 
data associated with video conferencing sessions is useless 
if it is not-delivered "on time". On the other hand, traditional 
best-effort data services, such as file or e-mail transfer, are 
not affected by variations in latency. QoS (Quality of 
Service) services deliver a defined network throughput for 
designated traffic by allocating dedicated bandwidth, priori- 
tizing data traffic, etc. (Note that as an alternative to pre- 
defined throughput, some QoS protocols can also offer a best 
effort (i.e., variable) throughput QoS based on available 
network capacity.) 

The following list provides a description of various Qual- 
ity of Service parameters. 

connection establishment delay — time between the con- 
nection request and a confirm being received by the 
requester 

cormection establishment failure probability — chance that 
the connection will not be estai>lished within the maxi- 
mum establishment delay 

throughput — bits per second (bps) of transmitted data 

transit delay — time elapsed between when sender trans- 
fers packet and recipient receives packet 

residual error rate — number of lost or corrupted messages 
compared to total messages in the sampling period 

transfer failure probability — the firaction of the time when 
the throughput, transit delay, or residual error were not 
those agreed upon at the start of the connection 

cormection release delay — time between when one node 
initiates a release and the other node performs the 
release 

connection release failure probability — fraction of release 
attempts which do not succeed 
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protection — specifies a secure connection 
priority — indicates traffic priority over the connection 
resilience — probability that the transport layer spontane- 
ously terminates 
QoS can be achieved in various ways as listed below: 5 
Specialized QoS Communications Protocols — provide 
guaranteed QoS. 

Asynchronous Transfer Mode (ATM) — ATM is a 
connection -oriented wide area and local area net- 
working protocol that delivers QoS on a per- lo 
connection basis. QoS is negotiated as part of the 
initial connection set up and as network conditions 
change. Because of the small size of ATM data cells, 
QoS can be better managed, compared to protocols 
such as Ethernet that have large frames that can tie 
up network components. For ATM to deliver QOS to 
applications, ATM must be used end-to-end. 

Resource Reservation Protocol (RSVP) — ^The emerg- 
ing RSVP specification, proposed by the Internet 
Engineering Task Force (lETT), allows applications 20 
to reserve router bandwidth for delay-sensitive IP 
traffic. With RSVP, QoS is negotiated for each appU- 
cation connection. RSVP enables the network to 
reserve resources from end to end, using Frame 
Relay techniques on Frame Relay networks, ATM 25 
techniques on ATM, and so on. In this way, RSVP 
can achieve QoS across a variety of network 
technologies, as long as all intermediate nodes are 
RSVP-capable. 
IP Stream Switching — improves network performance 30 

but does not guarantee QoS. 

IP Switching — IP Switching is an emerging technology 
that can increase network throughput for streams of 
data by combining IP routing software with ATM 
switching hardware. With IP Switching, an IP switch 35 
analyzes each stream of packets directed from a 
single source to a specific destination, and classifies 
it as short- or long-lived. Long-lived flows are 
assigned ATM Virtual Channels (VCs) that bypass 
the IP router and move through the switching fabric 40 
at the full ATM line speed. Short-lived flows con- 
tinue to be routed through traditional store-and- 
forward transfer. 

Tag Switching — Like IP Switching, emerging Tag 
Switching technology also improves network 45 
throughput for IP data streams. Tag Switching aggre- 
gates one or more data streams destined for the same 
location and assigns a single tag to all associated 
packets. This aUows routers to more efficientiy trans- 
fer the tagged data. Tag Switching is also known as 50 
Multiprotocol Label Switching. 
Data Prioritization — improves network performance but 

does not guarantee QoS. 

While not an example of end-to-end QoS, various 
network components can be configured to prioritize 55 
their handHng of specified types of traffic. For 
example, routers can be configured to handle legacy 
mainframe traffic (SNA) in front of other traffic (e.g., 
TCP/IP). A similar technique is the use of prioriti^ 
circuits within Frame Relay, in which the Frame 60 
Relay network vendor assigns different priorities to 
different permanent virtual circuits. 

Prioritization techniques are of limited effectiveness if 
data must also pass through network components 
that are not configured for prioritization (e.g., net- 65 
work components run by third party network 
providers). 
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Network Media Services 2416 

The Network Media layer provides the following capa- 
bilities: 

Final framing of data for interfacing with the physical 
network. 

Performing, receiving, interpreting and acting on signals 
from the communications fabric. 

Transferring data through the physical netwodc. 

The technologies used at the Network Media Services 
layer vary depending on the type of network under consid- 
eration. 

Media Access 2418 

Media Access services manage the low-level transfer of 
data between netwodc nodes. Media Access services per- 
form the following functions: 
Physical Addressing— The Media Access service encap- 
sulates packets with physical address information used 
by the data link protocol (e.g., Ethernet, Frame Relay). 
Packet Transfer — The Media Access service uses the data 
link communications protocol to frame packets and 
transfer them to another computer on the same 
network/subnetwork. 
Shared Access — The Media Access service provides a 
method for multiple network nodes to share access to a 
physical network. Shared Access schemes include the 
following: 

CSMA/CD— Carrier Sense Multiple Access with Colli- 
sion Detection. A method by which multiple nodes can 
access a shared physical media by "listening" imtil no 
other transmissions are detected and then transmitting 
and checking to see if simultaneous transmission 
occurred. 

token passing — ^A method of managing access to a shared 
physical media by circulating a token (a special control 
message) among nodes to designate which node has the 
right to transmit 
multiplexing — ^A method of sharing physical media 
among nodes by consolidating multiple, independent 
channels into a single circuit. The independent chan- 
nels (assigned to nodes, applications, or voice calls) can 
be combined in the following ways: 
time division multiplexing (TDM) — use of a circuit is 
divided into a series of time slots, and each inde- 
perKlent channel is assigned its own periodic slot, 
frequency division multiplexing (FDM) — each inde- 
pendent charmel is assigned its own frequency range, 
allowing all channels to be carried simultaneously. 
Flow Control — The Media Access service manages the 
flow of data to account for differing data transfer rates 
between devices. For example, flow control would have 
to limit outbound traffic if a receiving machine or 
intermediate node operates at a slower data rate, pos- 
sibly due to the use of different network technologies 
and topologies or due to excess network traffic at a 
node. 

Error Recovery — ^The Media Access service performs 
error recovery, which is the capabiUty to detect and 
possibly resolve data corruption that occurs during 
transmission. Error recovery involves the use of 
checksums, parity bits, etc. 

Encryption — The Media Access service may perform 
encryption. (Note that encryption can also occur within 
the Communications Services layer or the Transport 
Services layer.) Wthin the Network Media Services 
layer, encryption occurs as part of the data link protocol 
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(e.g. Ethernet, frame relay). In this case, all data is The following are examples of wireless physical media: 

encrypted before it is placed on the wire. Such encryp- cellular antennas and the associated radio frequencies 

tion tools are generally hardware products. Encryption wireless local area network antennas and the associated 

at this level has the advantage of being transparent to radio frequencies 

higher level services. However, because it is dependent 5 satellite antennas and the associated radio frequencies 

on the data link protocol, it has the disadvantage of Transaction 10124014 

requiring a different solution for each data link proto- A transaction is a unit of work that has the following 

col. (AQD) characteristics: 

The following are examples of Media Access protocols: A transaction is atomic; if interrupted by failure, all effects 

Ethernet lo are undone (rolled back). 

token ring ^ transaction produces consistent results; the effects of a 

pj^pj transaction preserve invariant properties. 

r t- * J J A transaction is isolated; its intermediate states are not 

portions of the ATM standard visible to other transactions. Transactions appear to 

HDLC/SDLC 15 execute serially, even if they are performed concur- 

LAPB rcntly. 

T-carrier, E-carrier (e.g., Tl, T3 El E3) ^ transaction is durable; the effects of a completed 

TDM and FDM (Tune DiWsion Multiplexing and Pre- a ^^^'^"hic fT^^^ ^""'^ ^^"""^^^ '° 

quency Division Multiplexing; used on T-carriers, etc.) ^„ a op ic mure;. 

^ ^ 20 A transaction can be termmated m one of two ways: the 

^UNtJ, transaction is either committed or rolled back. When a 

PPP, SLIP transaction is committed, all changes made by the associated 

V.32, V34, V:34 bis, etc. requests are made permanent. When a transaction is rolled 

RS-232, EIA-232 h^k^ all changes made by the associated requests arc 

TDMA and FDMA (lime Division Multiple Access and ^ ^t™Jo^™ . • • j *u *. ^ - . 

Frcquency Division Multiple Access; uid on wireless T f T^t. u ^"^S^^^ 

j^jjj^x ^ mechaman for the application. This allows all data activities 

c«^««iL=^ -* u * jji * within a single business event to be grouped as a single, 

Speaalized services convert between addresses at the ^ work. 

Media Access level (i.e., physical addresses like Ethernet) °??^J^i*° J^j*^ * i • . n ^ ^^n. 

D„«i,«* t:^^ /¥ * — ♦„ 1 • 1 1 /- / ^0 1° small to moderate scale environments of less than 150 

and the Packet Forwarding/Internetworking level (i.e., net- . . , . . . , 

work addresses like IP) The following protocols arc "^"^''l ^ """^^ "^'^ ^ 

examples of this fimctionality: ^^^^ ^^^^ rc-start/recovery 

.S^ . ^. and integnty capabilities. 

ARP (Address Resolution Protocol)-aUows a node to por larger cUent/server environments distributed on-line 

obtain the physical address for another node v^en only 35 transaction managers might be more apphcable. These trans- 

the IP address is known. action managers provide sharing of server processes across 

RARP (Reverse Address Resolution Protocol) — ^allows a a large community of users and can be more efficient than 

node to obtain the IP address for another node when the DBMSs. 

only the physical address is known. FIG. 26 illusti^ates several of the components of the 

Possfcle Product Options 40 Transaction areas of the Netcentric Architecture Frameworic, 

Semaphores Network Security System for Worl^ups each of whidi will be discussed in more detail below. 

Semaphore's Network Security System for Transaction Monitor 2602 

Workgroups — encrypts Ethernet. The Transaction Monitor Services arc the primary inter- 
Physical Media 2420 face through which applications invoke Transaction Ser- 
As illustrated in FIG. 25, the Physical Media is divided 45 vices and receive status and error information. Transaction 
into two categories: Monitor Services, in conjunction with Information Access 

1) , the physical connectors 2502 ^ Communication Services provide for load balancing 

2) , the physical media (wired or wireless) 2504 r^"^"^"^^- ""^^^^^ transparency for 
Physical Connectors distributed transaction processmg. 

4%,^ • 1 c ' ' ^ J . 50 Implementation Considerations 

1 ne lollowing are examples of winng coimectors used to A .1. . . • , , « 

connect network nodes to physical media: ^"^^^^ nonrelataonal data? 

PI 11 BT_A<; 5>ome IP momtors provide a method of accessmg non- 

KJ-11, RJ-45 relational data, such as VSAM files or flat files, indepen- 

BNC dently of where the file physically resides. If write access is 

DB-9, DB-25 55 required for these data sources, a TP monitor would provide 

fiber optic connectors dependable messaging and two-phase commit capa- 

Physical Media bilities than the data source messaging capabilities alone. 

Physical Media may be wired or wireless. Wired Physical ^® ^y^tem require high throughput? 

Media includes wiring and cabling, while wireless Physical Because TP monitors provide load balancing functionality 

Media includes antennas, connectors, and the radio &c- ^ ^ because they effectively reduce the number of connec- 

quency spectrum. ^ made to the databases), they will help 

The following are examples of wired physical media: conserve the resources of the data servers and, as a result, 

twisted pair wiring, shielded twisted pair wiring increase the throughput of the system. Systems with high 

coaxial cable throughput requirements should consider using a TP moni- 

65 tor. 

fiber optic cable Do the on-line applications need the support of interop- 

4-pair voice-grade wiring erability between autonomous, heterogeneous processors? 
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Some TP monitors are available od multiple platfomis and Is the system not a transaction processing system? 

maintain interoperability (conmiunication, data translation, Althon^ TP monitors provide glc^al two-phase commit 

etc.) between heterogeneous resource managers (databases) "transaction processing" functionality, systems that do not 

and clients (UNIX, MS Windows NT, etc.). For this reason, need this feature can also benefit by using TP monitors. For 

projects that intend to support a heterogeneous hardware 5 example, the load-balancing feature in itself can help 

environment should consider using a TP monitor. increase system performance. Also, the administrative facili- 

Is the system supposed to be highly available (i.e. 24x7), ties can help simplify system management, 

or mission critical? Is Data Dependent Routing Necessary? 

TP monitors offer robust functionality: two-phase Data Dependent Routing is the ability to route requests to 

commit, recovery/rollback, naming services, security 10 a particular server based upon the data passed within the 

services, can guarantee message delivery, can be maintained request. TP monitors can provide this functionality, e.g. A 

for high-availabiUty operation and provides aiidit trail log- system has several servers accepting requests from clients 

ging. Therefore, the more mission critical the system, the dispersed across North America. There are two groups of 

more likely it is that a TP monitor should be used. servers. One group of servers bandies requests from all 

Does the system require high availability? 15 clients located in the USA while the other group serves 

Because of their fault tolerance, TP monitors make a requests from Canada. When a cheat sends a request to the 

valuable addition to systems that require high availability. system, a field in the request message, defining the location 

The automatic restart/recovery feature helps a system rec- of the client, is passed to the system. The TP monitor is then 

ognize when components have failed and attempts to restart able to route the request to the correct group of servers (USA 

them. Also, because of the location transparency feature of 20 or Canada) based upon information in the request message, 

service calling, if an entire node in a system goes down, Is Reliable Queueing Necessary? 

clients may be able to reach the service they need on another I'P monitors provide the ability to enqueue and dequeue 

node providing the same service. requests to and from a reliable (stable storage) queue. Both 

Wm the system be scaled in the future? the application and the administrator can control the order of 

TP monitors offer multiple scalability options. TP moni- ^ messages (service requests) in the queue. Messages can 

tors can run on machines ranging from PCs to mainframes. *^ ordered LIFO, FIFO, time based, priority, or by some 

Monitors also scale by allowing new machines to be added combination of these keys, 

dynamically to the system. Adding additional nodes in the Example 

production cycle is one TP monitor strength, although some ^ system updates a customer database. Suppose that the 

monitors are better at doing this than others. If it is antid- ^ database has been partitioned such that the information on 

pated that system volumes will increase during the system 's customers most likely to use a branch office is stored locally 

lifetime, scalability in itseffis an excellent reason to use a TP ^ branch office. There is a requirement to maintain an 

monitor. up-to-date of the entire customer database at the home office. 

Does the system have complex security requirements? application that updates the local customer master can 

All of the TP monitors avaflable today provide security * "P^^^ ^ reUable queue. The queue 

authorization/authentication services. Most of them utilize ^ forwarded to the home office via a WAN, and the 

the Kerberos security package, developed at the Massachu- updates can be replicated m the home office database. The 

setts Institute of Technology (MIT). quemng system can be used to assure that every update 

Does the system access legacy systems? completed at the local office is completed at the home office. 

TPmonitorscanaccessdatabasesandservicesrmmingon ^ Is The System Multi-tiered? 

mainframe systems. TP monitors frequently inchide main- Transaction Services are tj^pically used m three-Uer and 

frame networidng capability and maintain transaction roU- "^^l^i-tier architectures. Particularly m Netcentnc 

back during mainframe accesses. If access to the legacy <^ov«^nments, apphcaUons niight need to support getting 

system is read only, the messaging capabiHties of the data ^ Providing access to multiple back-end services, across 

source will probably be sufficient. If access is write, enterpns^, as part of a single trar^ction or user ^^^^^ 

however, the messaging and two-phase commit capabilities ^, espeaally challengmg if the user does not own 

of the TP monitor would be more dependable. ^"^^ ^ f back-end services and/or data that its 

Is the system distributed across multiple nodes? S??^^!*^" 

~ J - • * r M -.* . Product Considerations 

TP monitors provide common admmistraUve facilities to ^„ , ... .^^ ♦ j • . ui • * u i • o 

^ r -I-.- 11 . . 50 Is the chent mterested m stable or emergine technologies? 

manage groups of servers. These facihties allow a system to 1™,^^^ u - 1^ r 

u „ 1 -^L . r TUXEDO has been m the TP marketplace for seven years 

be managed from one location with a common set of a u 4U * • * n r n -Jv. • . 

f r L ^d has the most installations of all TP momtors. Enema, 

commands for each machme. TYMjcxm Ar^r^t?i<nr^ 1 1 j - 

, , rOP END, and CICS/oOOO are relatively new and emergme. 

How many users access the system concurrently? ^toes the client plan to use \\rmdows NT? 

Different sources give different answers as to the number 55 On Which platforms/operating systems do the servers 

of concurrent users that necessitates the use of a TP monitor. jm,? 

The monitor vendors themselves give low values; the data- xp monitor support for NT may be limited, 

base vendors give high values. The middle ground seems to Some TP monitors are capable of running on a wider 

be somewhere around 250 users. This is by no means variety of platforms/operating systems than others, 

definitive, however; weigh each of the foUowmg questions Is the project installing a new system or rehosting/ 

when making the choice. downsizing an existing mainframe system? 

Do the on-line applications access/update more than one The UniKix, VIS/TP, and acS/6000 monitors were 

database or more than one type of database? developed specifically with rehosting in mind. TUXEDO, 

The real strength of TP monitors is their ability to ensure Endna, and TOP END are best suited to fresh installations, 

a global two-phase commit over multiple, heterogeneous 65 Does the system use PC-based clients? 

databases. A system that has this quality is a candidate for a Each TP monitor offers different support for PC-based 

TP monitor. clients. TUXEDO and TOP END currenUy provide DOS, 
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\N^dows, and OS/2 application programming interface 
(API) support. Endna offers PC support, but this feature is 
still in beta test. Several vendors have PowerBuilder and 
^^ual Basic interfaces planned for their monitors, but as of 
this practice aid's printing, nothing has been released. 

On which platforms will client applications execute? 

New and re-engineered systems may be required to 
execute on a previously installed base of clients. 

Does the system require integration with other 3rd party 
tools? 

Ihe client may expect the TP monitor to integrate with an 
already installed base of 3rd party development tools. 
Does the system require mainframe connectivity? 
Of the four monitors that are evaluated in this practice aid, 
all of them offer varying levels of mainframe connectivity. 

Does the client have existing personnel with 
mainframes — OCS experience? 

CICS/6000 has a programming interface similar to main- 
frame aCS. The learning cmve for mainframe dCS pro- 
grammers to use aCS/6000 would be minimal; for these 
same personnel to program using TUXEDO, Eocina, or TOP 
END, the learning curve would be substantial. On the other 
hand, because CICS/6000's administrative facilities are not 
similar to mainframe CICS, administrative personnel will 
face a steep learning curve: they will need to leain UNDC, 
DCE, and Encina (the layers on \^1iich aCS/6000 is built). 
(NOTE: VIS/TP and UniKix are also implementations of 
CICS in the UNIX environment, but they ere not included in 
this evaluation.) 
Possible Product Options 

'I\ixedo; aCS/6000; Encina; MS Transaction Server; 
Sybase Jaguar, TOP END; openUTM; TransIT Open/OLTP 
Below are commonly used transaction monitors: 
BEA TUXEDO — provides a robust middleware engine 
for developing and deploying business-critical client/ 
server applications. BEA TUXEDO handles not only 
distributed transaction processing, but also application 
and the full complement of services necessary to build 
and run enterprise-wide applications. It enables devel- 
opers to create applications that span multiple hardware 
platforms, databases and operating systems. 
IBMs CICS/6000 — an application server that provides 
industrial-strength, onUne transaction processing and 
transaction management for mission-critical applica- 
tions on both IBM and non-IBM platforms. CICS 
manages aiKl coordinates all the different resources 
needed by applications, such as RDBMSs, files and 
message queues to ensure completeness and integrity of 
data. 

Transarcs Encina — ^implements the fundamental services 
for executing distributed transactions and managing 
recoverable data, and various Encina extended 
services, which expand upon the functionality of the 
toolkit to provide a comprehensive environment for 
developing and deploying distributed transaction pro- 
cessing. 

Microsofts Transaction Server (\^r) — a component- 
based transaction processing system for developing, 
deploying, and managing high performance, and scal- 
able enterprise, Internet, and intranet server applica- 
tions. Transaction Server defines an application pro- 
gramming model for developing distributed, 
component-based applications. It also provides a run- 
time infrastmcture for deploying and managing these 
applications. 
Brief Product Considerations 

Encina— The Encina DTP (OLTP) was built on top of 
OSF's DCE. This is both its greatest asset and curse. 
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DCE offers a very complete set of functions including 
security services, RPC's, a directory service (like a 
yellow pages for clients to find services) and a standard 
time service, and it is truly cross-platform and is 
endorsed by most vendors. The problem is that it is a 
resource hog, and is fairly slow. DCE is also somewhat 
immature in that there are not many tools to help you 
administer or program applications (although many are 
on the way). Encina adds primarily a transactional 
element and some load balancing services to RPC's. It 
also provides an easier interface to work with (although 
it is still an administrative nightmare). 

The good news is that the tools are getting better all of the 
time. Also, Encina is very scalable and services can be 
on any machine in the netwoik. Finally, Encina's load 
balancing is quite good, much better then native DCE 
or Tkxedo. 

Tuxedo 

Functionality 

Can handle a large number of concurrent client apphca- 
tions 

Can handle a large volume of through-put (ex. 1000+TPS) 
Scaleable (handle many chents or a few without code 
rewrite) 

Supports Transactions, including XA transactions 

Has its own transaction resource manager 

Guaranteed message delivery using a stable storage queue 

(/Q) 

Future service delivery using /Q (usually for batch 
processing) 

Can prioritize messages — most important get processed 
sooner. 

Supports many platforms (all UNIX, NT, all common 

client platforms) 
Tuxedo supports C, C++, and Cobol development 
Can be used for basic c/s messaging 
Supports conversational messaging between a client and 

a specific server 
Peer-to-peer, client-to-client messaging is supported 
Unsolicited messaging is supported for client processes 
Asynchronous service calls can be made by client and 

server processes 
Synchronous service calls can be made by client and 

server processes 
Synchronous calls that receive no return message are 

supported 

Very good security — must connect to access services 

Security can be integrated w/Kerberos 

Has many different buffer types: view to pass C stnicts, 

FML to pass anything, carrays to pass binary (sound, 

video), strings to pass strings 
FML allows dynamic messages to be sent/received 
Automatic error logging for Tbxedo components (ULOG, 

tagent log) 

Application code can write to the ULOG with a Tuxedo 

API (error legging provided) 
Automatic process monitor for process that die or 

machines that get partitioned 
Service location independency (distribution/directory 

services) 

Platform independency — bandies data conversion 
Built in data compression (if desired) 
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Built in performance measurement feature for services Atomicity — all changes are made completely 

Built in admin functions to monitor Tuxedo system online (committed) or not at all (roll-back), 

(tmadmin) Consistency — the effects of a transaction preserve invari- 

A server can be called based on data in the message (Data ant properties. 

Dependent Routing) ^ Isolation— intermediate data values are not visible to 

Customizable server start-up and shutdown functions are olher transactions. 

automatically called Durability— the effect of a completed transaction are 

/Domains allow independent Tuxedo regions to share persistent. 

services Two-Phase Commit is a feature found in distributed 

Extensions to execute IMS and QCS transactions &om database management systems and online transaction pro- 
UNIX (Open Transport) cessing (OLTP) monitors to ensure information integrity 

Subscribe and Broadcast supported f"^"^ distributed databases. With this feature, a transaction 

j ^ °°^y commited if two databases have the necessary 

APIs to get admm and system momtormg data for custom information. If a problem arises on a network connection or 

operation tools ^ computer, the software will roll the transaction back so it 

JOLT (java to access 'nxxedo servers) will not be entered in either place. A restart mechanism may 

Other Reasons to Use T\ixedo then retriy to complete the transaction. 

Tuxedo is the market leader OLTP Possible Product Options 

Tuxedo is a proven product used in mission critical 20 T^«^o; Encina; TOP END; aCS/6000; openUTM; Tran- 

systeins govt, and financial) sIT Open/OLTP 

Tuxedo can be used to develop highly-available systems Partitioning 2608 

(24x7) Transaction Partitionmg Services provide support for 

UK . , * J Ti T^ij . mapping a single logical transaction in an application into 
H^^been miplemented with PowerBuilder, VisualBasic, ^ the required multiple physical transactions. For example, in 

Motif clients, and unix batch systems. ^ package or legacy rich enviromnent, the single logical 

Cons of Using Tuxedo transaction of changing a customer address may require the 

Tuxedo for basic c/s messaging is overkill. partitioning and coordination of several physical transac- 

Expensive to purchase to multiple application systems or databases. Transac- 

Can be complicated to develop with and administer ^ Partitioning Services provide the application with a 

„ , - . . . simple smgle transaction view. 

System performance tunmg requires an experienced Tux- Implementation Considerations 

edo administrator * *u * ^ i • i . 

J t. ^ L , , . system support logical transactions that occur 

Uses IPC resources and therefore should not be on same across heterogenous appUcation servers and databases'? 

machine w/other IPC products 35 Example 

Must be understood thoroughly before design starts. If ^ gi^en application, a single business process of 

used mcorrectiy, can be very costly. updating a customer record requires an update to a table 

Single threaded senders requires an upfront packaging in a UNIX based relational database and then an update 



to a table in a MVS DB2 database. Although there are 
Difficult to debug servers ^ two physical transactions occurring, this entire business 

Does not work well with Pure Software products: Purify, process is represented as a single logical transaction. 

Quantify ' Transaction Partitioning services allow the application 

Servers must be programmed to support cUent context that themdividual tr^^ ocairr across 

data management different UNDC and MVS systems and that the 

r*;fK^.i* * A u • o J _^ J ^^^^ logical transaction is completed and successful 

Difficul to do asynch messaging m 3rd party Windows ^hen the individual physical transactions are com- 

3.x chent tools (ex^ PowerBmlder) successful. 
Resource Mamigement 2604 Environment 1016,1018 

.n^'^T'Tt "^^1 ^hT concurrency control 37 illustrates various components of the Environ- 

and mtegnty for a smgular data resource (e.g., a data base or 50 * 1 e * ^ *u xt . y^^y^^^^^ ^ j-uvuuii 
, «i» I ♦ •* • * J u * L mental Services of the Netcentnc Architecture Frameworic. 

Environment service provi^^ miscellaneous appHcati^ 

Resouree Man^ement ServiL use locking, commit, and ^tl^^"^ l'""^^ ^^^^ ^."^ .^"^^^ 

rollback servicS, and are integrated with Transaction Man- '^"""^"'^ user-interface, commumcatmg to other 

agement Service; 55 ST""^.'"' ""^^ 
Transaction Management 2606 ^'^^^^ ^"^^^.^ 

Transaction Management Services coordinate transac- ^^^^^ services convert non-compUed computer lan- 
tions across one or more resource managers either on a ""^^ execution of a pro- 

single machine or multiple machines within the network. SX^- 

Transaction Management Services ensure that aU resources 60 ^S^^Se Interpreter 2704 

for a transaction arc updated, or in the case of an update . language Interpreter Services decompose a 4th genera- 
failure on any one resource, all updates are rolled back ^^^^ * scripting languages into machine code 

This services that allow multiple appUcations to share (executable code) at runtime, 
data with integrity. The transaction management services Possible Product Options 

help implement the notion of a transaction — ^a set of com- 65 VBRUN300.DLL 

putations producing changes to recoverable data which VBRUN300.DLL— runtime Dynamic link Library that 
demonstrate the ACID properties: supports programs written in Visual Basic. 
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\%tual Machine 2706 ImpIemenlatioD Cbnsiderations 

Typically, a Virtual Machine is implemented in software In client/server applications, it may be necessary to imple- 

on top of an operating system, and is used to run applica- ment Environment Verification Services to ensure that the 

tions. The Virtual Machine provides a layer of abstraction client and server applications are of a compatible release 
between the applications and the underlying operating sys- 5 level. 

tem and is often used to support operating system indepen- ActiveX framework provides services for automatic 

^^^cc- installation and upgrade of ActiveX controls. When using 

Possible Product Options IE, ix., Microsoft's Web browser, because of its integration 

Java virtual machine; SmaUtalk virtual machine with Windows OS, ActiveX controls can be automaticaUy 

\lrtual machines such as the Java virtual machine or the installed and automaticaUy upgraded on the usere machine 

SmaUtalk virtual machme unplement their own versions of vvithout the developer adding any additional code. 

^^^m^l^l^'^l^f^M application jask and Memory Management 2716 

, ^L- 1 , . « Task & Memory Management Services aUow applications 

"'rpTrnl;!'^^'^ h7 ll!?*''^!^ ^-^ '^"^ ^^^^ to «'°t«>' individual computer tasks or 

CPU designed to run compiled Java byte code. This ^ -m. *j - ir 

includes sl^d-alone Java applicationT as well as « P^^^, and manage memory. TTiey provide ser>^^ 

"applets" that are downloaded iid run in Web brows- ^^^^l' f^mg. stopping, and restartmg both chent and 

gjjg server tasks (e.g., software agents). 

SmaUtaUcvirtualmachin^^runtimeenginethatinterprets I^'Pjementation Considerations . , 

application code during execution and supports plat- , ^^"^"""y management, the allocatmg and freemg of sys- 

form independence. 20 resources, is one of the more error prone development 

System Services 2708 activities when using 3GL development tools. Creating 

Services which appUcations can use to perform system- architecture services for memory handUng functions can 

level functions. These services include: System Security reduce these hard to debug errors. 

Services, Profile Management Services, Task and Memory ^^^^ removes, in theory, the problem of memory 
Management Services, and Environment Verification Ser- 25 management, by providing a garbage coUecton although, its 

vices. implementation is not very efScient in current implementa- 

System Security 2710 tions of Java. Future releases of the Java VM promise a 

System Security Services aUow applications to interact background-rurming garbage coUector with significantly 

with the operating system's native security mechanism. The increased performance, 
basic services include the ability to login, logoff authenti- 3Q ^^ptication Services 2718 

cate to the operating system, and enforce access control to AppUcation Services are miscellaneous sendees which 

g^tem resources and executables. appUcations can use for common functions. These common 

Profile Management 2712 fimctions can apply to one application or can be used across 

Profile Management Services are used to access and appUcations. Hiey include: V^pHcation Security Services, 

update lcK:d or remote system, user, or aK^^^^^^ HandUng/Logging Slices, State Managemen 

^rr^Mfnn';f°h f.T ' ^ "^"^ Services, Help Servi^s, Ind Other Common Sei^^ 

mformation such as the user's language and color prefer- A«„nv«t;«« <^l^.«t,, '>?>n 

ences to basic job function information which may be used >W^calion 5>ecunty 2720 , , . . 

by Integrated Performance Support or Workflow Services. Besides system level secunty such as loggmg mto the 

Implementation Cbnsiderations network, there arc additional security services associated 

Is there a need for the appUcation to have its own profile 40 with specific appUcations. These include: 

file? User Access Services — set of common functions that limit 

AU MS Wndows based appUcation maintain their own appUcation access to specific users within a company or 

profile file pDDDCXXXX.INI) that is used during appUca- external customers. 

tion startup, execution, and shutdown. This is a flat text file Data Access Services — set of common functions that Unut 

that contains information that can be used by the appUcation 45 access to specific data within an appUcation to specific 

during various phases of execution. For example, if an users or user types (e.g., secretary, manager), 

application needs to connect to a database engine/server, it Function Access Services— set of common functions that 

needs to know, during startup, various information Uke — Umit access to specific functions within an appUcation 

database name, the server name, login ID, etc. Instead of to specific users or user types (e.g., secretary, manager), 

hard coding all these information in the appUcation 50 Implementation Considerations 

executable, this information can be stored in the profile file In the Netcentric environment, application security 

for flexibiUty, In the future, if the database server name becomes a more critical component primarily because there 

should change, this change only needs to be entered in die are more types of users (e.g., employees, customers) and 

aj^lications profile file. In some cases, it has been seen that additional types of transactions (e.g., e-commerce, help- 

this profile information has been hard coded in that appU- 55 desks). In traditional cUent/server environments most users 

cations executable itself. This will work, but, it makes the are employees of the company In Netcentric environments 

application more rigid with no room for any flexibiUty. there are typicaUy also external users (e.g., vendors, regis- 

Environment Verification 2714 tered users) and the general pubUc. Usually, different types 

Environment Verification Services ensure functionaUty by of users have different application security requirements 

monitoring, identifying and vaUdating environment integrity 60 Umiting what data they can see and what fimctions they can 

prior and during program execution, (e.g., free disk space, execute. Also, new of transactions such as verifying 

monitor resolution, correct version). These services are credit when doing e-commerce transactions also require 

invoked when an appUcation begins processing or when a additional appUcation security services, 

component is called. v^Ucations can use these services to Error Handling/Logging 2722 

verify tiiat the correct versions of required Execution Archi- 65 Error HandUng Services support the handUng of fatal and 

lecture components and other appUcation components are non-fatal hardware and software errors for an appUcation. 

available. An error handling architecture takes care of presenting the 
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user with an understandable explanation of what has hap- Management Services (storing state information on the 
pened and coordinating with other services to ensure that server). The HTTP protocol is a stateless protocol Every 
transactions and data are restored to a consistent state. connection is negotiated from scratch, not just at the page 
Logging Services support the logging of informational, level but for every element on the page. The server does not 
error, and warning messages. Logging Services record appli- 5 maintain a session connection with the client nor save any 
cation and user activities in enough detail to satisfy any audit information between client exchanges (i.e., web page sub- 
trail requirements or to assist the systems support team in mils or requests). Each HTTP exchange is a completely 
recreating the sequence of events that led to an error. independent event. Therefore, information entered into one 
Implementation Considerations HTML form must be saved by the associated server appli- 
Error Handling cation somewhere where it can be accessed by subsequent 

Primarily there are three types of errors: system, archi- programs in a conversation, 

tecture and application. Advances in Netcentric technologies now offer additional 

System errors occur when the application is being options for implementing state management on both the 

executed and some kind of serious system-level incom- client and server machines, 

patibility is encountered, such as memory/resource 15 Possible Product Options 

depletion, database access problems, network problems NetDynamics Inc. NetDynamics 

or printer related problems, because of which the NetDynamics Inc. NetDynamics 

appHcation cannot proceed with its normal execution. NetDynamics provides built-in, developer-definable ses- 
Architecture errors are those which occur during the sion and state management. The Persistence Engine 
normal execution of the apphcation and are generated 20 (PE), part of the NetDynamics appUcation server, 
in architecture functions that are built by a project stores all relevant information about a user. Everything 
architecture team to isolate the developers from com- from the WebID to the exact table row the user is 
plex coding, to streamline the cfevelopment effort by currenUy viewing can be maintained in the PE. Net- 
re-using common services, etc. These architecture Dynamics maintains state information on both the 
functions perform services such as database calls, state 25 server and on the cHent page, i^phcation state infor- 
management, etc. mation is maintained by the appUcation server, and 
y^lication errors are also those which occur during the local state information is maintained on the page, 
normal execution of the application and are generally NetDynamics provides manipulatable state objects for 
related to business logic errors such as invalid date, both server and page state information, 
invalid price, etc. 30 Codes Table Service 2726 
Typically an application is written using a combination of Codes Table Services enable applications to utilize exler- 
various programming languages (e.g., Msual Basic and Q. nally stored parameters and validation rules. For example. 
Therefore, a common error handling routine should be an application may be designed to retrieve the tax rate for the 
written in a language that can be called from any other State of Illinois. When the user enters "Illinois" on the 
language used in the application. 35 screen, the application first validates the user's entry by 
Logging checking for its existence on the ."State Tax Table", and then 
Logging must be done, however to mitigate problems, retrieves the tax rate for Illinois. Note that codes tables 
centralize logs and create a standard, usable log format. 3rd provide an additional degree of flexibility. If the tax rates 
party logs should be mapped into the central format before changes, the data simply needs to be updated; no application 
any analysis is attempted. 40 logic needs to be modified. 

In a Netcentric environment, errors are rarely logged on Implementation Considerations 

the cHent machine (one exception may be for an intranet Is there a need for the codes table functionality? 

type application). Most applications need code/decode facility. For 

Logging can add much stress to a Web server and logs can example, an application may need to store codes like — error 

grow very large, very quickly, so do not plan to log all 45 severity codes, etc., stored in a table (may be a cached table) 

errors^-capture only those which are deemed necessary for instead of in the executable itself. In some cases, where there 

processing exceptions. is a small amount of information that needs to be stored in 

State Management 2724 the codes table, the profile file (mentioned above) can be 

State Management Services enable infonnalion to be used instead of the codes table. But in cases where the codes 

passed or shared among windows and/or Web pages and/or 50 table needs to be used quite extensively, then storing the 

across programs. So lets say several fields in an application code/decode information in the profile file will slow down 

need to be passed from one window to another. In pseudo- the performance of the application because of the overhead 

conversational mainframe 3270 style applications passing of accessing flat files, 

data from one screen to another screen was done using What basic services an architecture should provide in 

Context Management Services that provided the ability to 55 terms of managing/using codes/decodes functionality? 

store information on a host computer (in this paper the term In cases where the application requires extensive use of 

Context Management refers to storing state information on codes table, the architectures Code/Decode component 

the server, not the client). Client/server architectures sim- should provide the application developers with a set of API 

plified or eliminated the need for Context Management that can be used to use code/decode tables. TTiis component 

(storing state information on the server), and created a need 60 should also provide the option of caching aU or parts of the 

to store state information on the chent. Typically, in tradi- codes table in the application machines memory for easier 

tional client/server systems this type of state management and faster access. 

(i.e., data sharing) is done on the client machine using Where ^ould Code/Decode information be stored and 

hidden fields, global variables, messages, files or local maintained? 

databases. 65 Code/decode information can be stored at any layer of an 

The popularity of the Internets HTTP protocol has revived n-tier architecture— client, application server, or database, 

the potential need for implementing some form of Context The decision wiU need to be based upon codes table size and 
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number, infomiatioa update fiFequency, and write-access to 
the client machine or device. 
Active Help 2728 

Active Help Services enable an application to provide 
assistance to a user for a specific task or set of tasks. 
Context-sensitive help is most commonly used in applica- 
tions today, however this can imply more "active" support 
that just the Fl key. Typically, today's systems must be 
architected to include Help that is aware of both the user's 
environment, process and context, and in this sense can be 
called "active". Active Help services may include compo- 
nents like Wizards for walking a user throii^ a new process, 
stored or real-time multi-media support, on-demand Com- 
puter Based Training, etc. 
Other Common Services 2726 

Catchall category for additional reusable roiUines useful 
across a set of applications (e.g.. Date Routines, Time Zone 
Conversions, Field Validation Routines). 
Implementation Considerations 

Does the client operate in different date/time zone? 

In most large scale distributed applications, the client and 
the server applications (or machines) are scattered over 
different time zones. This forces the client applications and 
the server hosts to deal with date and time zone conversions 
(like — CST to PST, etc.) in order to use or display their local 
time accurately. Most of the architectures provide a base set 
of APIs that can be used by the applications to convert the 
data/time as needed. 

Does the system requires customized date/time format for 
display purposes? 

Many systems, for certain business reasons, need custom- 
ized date and time formats for display and storage purposes. 
In order to do that, the architecture should provide a set of 
APIs that will allow the system to convert data and time 
from one format to the other. 

Does the system deal with high database accesses? 

As mentioned in the Codes Table Component, sometimes 
it is necessary to cache the data in the memory for faster 
access and less database hits. This a feature that some 
architectures provide as a set of memory management APIs 
to create the cadie area in the client platforms memory for 
the data to reside. 

Application Integration Interface 2734 

An ^plication Integration Interface provides a method or 
gateway for passing context and control of information to an 
external application. The ^plication Integration Interface 
specifies how information will be passed and defines the 
interface by which other applications can expect to receive 
information. External applications in this context could 
include anything from Integration Performance Support 
systems to ERP systems like SAP or Peoplesoft to external 
custom applications that have been previously developed by 
the client. 

Implementation Considerations 

Where possible. Application Integration Interfaces should 
make use of the Component Model defined by the project to 
broker information (i.e. OLE/COM interfaces) as opposed to 
custom building data sharing modules. 
Componeat Framework 2736 

Component Framework Services provide an infi"astruc- 
ture for building components so that they can communicate 
within an application and across applications, on the same 
machine or on multiple machines across a network, to work 
together. COM/DCOM and CORBA described in Commu- 
nication Services are the two leading component industry 
standards. These standards define how components should 
be built and how they should communicate. 
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Object Request Broker (ORB) services, based on COM/ 
DCOM and CORBA, focus on how components communi- 
cate. Component Framework Services, also based on 
CORBA and COM/DCOM, focus on how components 
should be built. The currently 2 dominant Component 
Frameworks include: 

1. ActiveX/OLE — ^ActiveX and Object Linking and 
Embedding (OLE) are implementations of COM/ 
DCOM. ActiveX is a collection of facilities forming a 
framework for components to work together and inter- 
act. ActiveX divides the world into two kinds of 
components: controls and containers. Controls are rela- 
tively independent components that present well 
defined interfaces or methods that containers and other 
components can call. Containers implement the part of 
the ActiveX protocol that allows for them to host and 
interact with components — forming a kind of back 
plane for controls to be plugged into. ActiveX is a 
scaled-down version of OLE for the Intemet. OLE 
provides a framework to build applications from com- 
ponent modules and defines the way in which applica- 
tions interact using data transfer, drag-and-drop and 
scripting. OLE is a set of common services that allow 
components to collaborate intelligently. 

In creating ActiveX from OLE 2.0, Microsoft enhanced 
the framework to address some of the special needs of 
Web style computing. Microsofts Web browser, Inter- 
net Explorer, is an ActiveX container. Therefore, any 
ActiveX control can be downloaded to, and plugged 
into the browser. This allows for executable compo- 
nents to be interleaved with HTML content and down- 
loaded as needed by the Web browser. 

2. JavaBeans — ^is Sun Microsystems proposed framework 
for building Java components and containers. The 
intent is to develop an API standard that will allow 
components developed in Java (or beans), to be embed- 
ded in competing container frameworks including 
ActiveX or OpenDoc. The JavaBeans API will make it 
easier to create reusable components in the Java lan- 
guage. 

Other component frameworks include: 

OpenDoc — CI Labs was formed in 1993 and created the 
OpenDoc architecture to provide a cross-platform alter- 
native component framework — independent of 
Microsofts OLE. The OpenDoc architecture is con- 
stmcted from various technologies supplied by its 
founding members — IBM, i^ple and Word Perfect. 
The technologies include: Bento (v^les object storage 
model). Open Scripting Architecture (OSA— .^^les 
scripting architecture) and SOM/DSOM (IBMs System 
Object Model/Distributed SOM). IBMs SOM architec- 
ture provides analogous services to that of Microsofts 
DCOM architecture. 

OpenDoc provides an open compound document infra- 
stmcmre based on CORBA. It uses CORBA as its 
object model for inter-component communications. 
OpenDoc architecture provides services analogous to 
those provided by OLE and OpenDoc components can 
also inter-operate with OLE components. The Open- 
Doc equivalent of an object is termed a part. Each type 
of part has its own editor and the OpenDoc architecture 
has responsibility for handling the communications 
between the distinct parts. 

Supporters claim OpenDoc provides a simpler, more 
technically elegant solution for creating and manipu- 
lating components than does OLE. The drawback is 
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thai OpenDoc is not yet commercially proven, like output to the user. This can include input validation 

OLE. Ironically, one of the more popular uses of requiring no additional server data, as well as simple 

OpenDoc tools is for creating and implementing OLE calculations associated with field (^lay. In addition, 

clients and servers. Because OpenDoc provides a more logic associated with dynamically changing the display 

manageable set of APIs than OLE, it may be that 5 (e.g., a checkbox entry causes a field to become 

OpenDoc gains initial acceptance as an enabler of OLE disabled) is placed here. 

applications before becoming recognized as a complete Process components typically contain the logic associated 

component software solution itself. with business transactions performed on data. This is 

ONE — Open Network Environment (ONE) is an object- often the point where transaction commit/rollback 

oriented software framework from Netscape Commu- jq occurs. These components are typically invoked by the 

nications for use with Internet clients and servers. User Interface components. 

which enables the integrating of Web clients and serv- Domain components typicaUy contain the logic associ- 

ers with other enterprise resources and data. By sup- ated with accessing and maintaining business entities, 

porting CORBA, ONE-enabled systems will be able to i.e., data. These components are usually invoked by 

link with object software from a wide array of vendors. Process components when requiring access to or 

mcludmg IBM,Sun Microsyste^^ manipulation of data. However, in addition to data 

and Hewlett.Packarf. Nets^^pe ^poationmg ONE as access, these components may often be used to perform 

an alternative to Microsoft s Distnbuted Common „o«^«.i„#;™ * 

Object Model (DCOM). ONE also complies with Sun mampulaUons involvmg the processmg of data withm 

Microsystems Java technology. component. For example, a Cus- 

Implementation Considerations 20 Domain component might be requested to deter- 

An architecture that utilizes components brings many of ^ '^'^ ^^^^ exceeded when 

the benefits of object orientation to applications. . provided with a new mvoice amount. 

Component-based or document-centric applications are Build vs. Buy 

composed ofintelligent components, each of which contains There is an explosion of components available in the 

logic, possibly data and a set of well defined interfaces or 25 P^*** ^ ®^ of accessing and down loading 

APIs to the services they provide (e.g., a customer compo- components from the Internet; the decision to buy or build 

nent or an Excel chart component). The simUarities to object f component is as real as ever. In general clients expect more 

oriented are more than just coincidental. Component soft- justification of a build decision v. a buy decision. Feel out 

ware is viewed by many as a more viable object approach ^ expectations and requirements they may 

focusing on laiger grain of modularity and reuse. 30 ^^a^^- 

TWo important issues driving the decision around what Components are a viable option and should be researched, 

should be a component are software re-use and software ^^^^ including even simple UI controls available on the 

packaging. Software re-use will primarily stem from defin- Internet. Look at market trends to determine which 

ing components at a level at which they can be re-used applications/components can meet the bulk of the system 
within the same application and across many applications. 35 

Although re-usable components can be at any level, more Operating System 2738 

often they will probably be at an object level where they are Operating System Services are the underlying services 

more granular. Software padcaging will be driven by defin- ^^f* ^ multi-tasking, paging, memory allocation, etc., 

ing components at a level at which they can be distributed typically provided by today's modem operating systems, 

effidendy to all users when business logic changes occur. If 40 ^^re necessary, an additional layer or APIs may be pro- 

the application is large, perhaps it is better to package the '° ^^^^ operating system independence or a 

application by breaking it up into process components such higher level of abstraction for application programmers, 

as customer maintenance, sales ortter maintenance, etc. So Possible Product Options 

when a change to one of the processes occurs, only the Microsoft Wndows; Windows 95; Windows NT; Macintosh 

component which contains that process needs to be distrib- 45 OS/2; Unix and Java OS 

uted to client machines, rather than the whole application. ®^ Services 1020 

For example, a developer can create an ActiveX control that Component Description 

wiU encapsulate the Employee Maintenance Process, which ^9* ^ illustrates the Base Services of the Netcentric 
includes adding new employees, updating and deleting Architecture Framework. Base Services provide server- 
existing employees. This ActiveX control can be a part of an so support for delivering applications to a wide variety of 
overall human resource intranet application. When the func- ^^^^ Internet, intranet, and extranet. The informa- 
tionality within the Employee Maintenance Process tion about these sendees in the Netcentric fiamework may 
changes, the next time the user accesses the human resource limited based on the least common denominator. For 
application from the Web browser, ActiveX technology will detailed information about these components refer also 
automatically download the latest version of the ActiveX 55 *° following frameworics in SAF and/or DAE 
control containing the most recent update of the Employee Batch Delivery Vehicle 

Maintenance Process to the client machine, if the client Collaboration Framework for Structured Information 

machine does not have the latest version. (Workflow) 

Component architectures typically employ of a three-tier Web Services (2820) 

component architecture utilizing the following three types of 60 Server Services enable organizations to manage and 

components: publish information and deploy Netcentric applications over 

User Interface, Process, and Domain. While these three the Internet and intranet environments. These services sup- 
component types may go by different names on different port the following: 

projects, they all follow the same basic pattern and are Managing documents in most formats such as HTML, 

briefly explained below: 65 Microsoft Word, etc. 

User Interface components typically contain nothing Handling of client requests for HTML pages. A Web 

more than the logic required to manipulate input and browser initiates an HTTP request to the Web server 
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either spedfying the HTML document to send back to pull services provide a mechanism for applications to be 

the browser or the server program (e.g., CGI, ASP) to notified in real time if a subscribed item changes (e.g., a 

execute. If the server program is qjecified, the Web stock ticker). Asynchronous push/^ull services do not 

server exeait^ the program which generally returns a require that a session-like connecUon be present between the 

formatted HTML page to the Web Server. The Web j subscriber and the information. Internet ListServeis are a 

f Ti^^^i^^^'^'uf S "'^ *™Pl« «^Pl«>- Subscribers use e-mail to register an inter- 
standaid HTML document back to Web brow«,r. est in a topic and are notified via e-mail when dhanges occur 
.TSm Gateway Interface or relevant information is available. Asynchronous push/puL 
(CGI), Acuve Server Pages (AS^. Sen^r side scnpt- ^^rvices can be useful for pro-actively updating cisto^ers 
2f ^™.rt LT*^ or commands to be executed on ^ ^^^^J i^rmalon on new 
the server machine providing access to resources Stored j , .... . u^.^ 
both inside and outside of the Web server environment. S'^^^^ f!^^ ^7^^^^ expressed an mterest in. 
For example, server side scripts can be used to process P^^^^^^ast; Marimba; IBlWLotus; Microsoft; Netscape; 
requests for additional information, such as data from Amenca Onlme; BackWeb; Wayfarer 
an RDBMS, Castanet from Marimba — distributes and maintains soft- 
Caching Web pages. The first time a user requests a Web ware applications and content within an organization or 
page, the Web server retrieves that page from the across the Internet, ensuring subscribers always have 
network and stores it temporarily in a cache (memory Ihe most up-to-date information automatically, 
on the Web server). When another page or the same PointCast — news network that appears instantly on the 
page is requeued, the Web server first checks to see if subscribers computer screen, 
the page is available in the cache. If die page is Batch Services (B2060) 

available, then the Web server retrieves it from the Batch processing is used to perform large scale repetitive 

cache, otherwise it retrieves it from the network. processing where no user involvement is required as well as 

Clearly, the Web server can retrieve the page from the reporting. Areas for design attention include scheduling, 

cache more quickly than retrieving the page again from recovery/restart, use of job streams and high availability 
its location out on the network. The Web server typi- ^ (e.g. 24 hour running). In addition close attention must be 

cally provides an option to verify whether the page has paid to performance as batch systems usually must be 

been updated since the time it was placed in the cache, processed within strict batch windows, 

and if it has to get the latest update. The design of batch architectures is often complicated 

Possible Product Options considerably by the fact that batch jobs must be able to run 

Netscape Enterprise Web Server; Microsoft Internet Infor- ^ concurrently with on-line systems. The general globalization 

mation Server 0IS); Oracle Webserver of companies requires that he on-line systems must be 

The followi ng are relevant products for providing or available on a close to 24x7 hours basis, eliminating the 

implementing HTTP Web Server Services: traditional batch windows. Concurrent batch and on-line 

Netscape Enterprise Web Server processing poses serious challenges to data integrity. 

An enterprise-strength Web server that enables organiza- throughput and performance. 

tions to manage and publish their information and Batch application programs can include business process- 
deploy Netcentric applications. Netscape Enterprise ^ig such payroll, billing, etc. and can also include report 
Web Server is built on open Internet standards that generation. This is an often overlooked area in client/server 
enable information and applications to scale easily. ^ architectures. Traditional client/server solutions and Netcen- 
S\q)ports S-HTTP, Java, and SNMR trie solutions often require batch processing, but unlike the 
Microsoft Internet Information Server (IIS) mainframe, the typical platforms and development environ- 
A free add-on product for NT Server that implements ^^^^ ^^"^^ built-in batch or reporting 
basic HTTP services. Future versions of NT Server (4.0 architecture faciKties. 

and beyond) will have HTTP features built directly into 45 ^^^^ processmg should be used in preference to on-line 

the operating system. modules when: 

Oracle Webserver The same process, or set of processes, must be applied to 

A mulU-threaded HTTP server that provides integrated entities in a repetitive and predictable fash- 
features for translating and dispatching client HTTP 

requests directly to the Oracle? Server using PL/SQL. 50 There is either no manual element to the process or the 

Pu^ Pull Services (2840) manual element can be completely separated from a 

Push/Pull Services allow for interest in a particular piece batch element, 

of information to be registered and then changes or new The volume of information to be presented to a user is too 

information to be communicated to the subscriber list. great to be processed on-line or it can be better printed 

Traditional Internet users "surf the Web by actively moving 55 in batch, 

from one Web page to another, manually searching for Related Patterns 

content they want and "pulling" it back to the desktop via a For more detailed information about component based 

graphical browser. But in the push model, on which sub- batch design patterns, refer also to the Batch patterns in the 

scription servers are based on, content providers can broad- Patterns section: 

cast their information directly to individual users' desktops. 60 Base Services Patterns Overview 

The technology uses die Internet's strengths as a two-way Abstraction Factory 

conduit by allowing people to specify the type of content Batch Job 

they want to receive. Content providers then seek to package BUW— Batch Unit of Work 

the requested information for automatic distribution to the Processing Pipeline 

user's PC. 65 Report Services (2880) 

Depending upon requirements, synchronous or asynchro- Report Services are facilities for simplifying the construc- 

nous push/pull services may be required. Synchronous push/ tion and delivery of reports or generated correspondence. 
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These services help to define reports and to electronically Report Execution (2902) 

route reports to allow for online review, printing, and/or Report execution is the core of the reporting apphcation 

archiving. Report Services also support the merging of framework. The main components of report execution 

application data with pre-defined templates to create letters include: 

or other printed correspondence. Report Services include: 5 Format the report. This function is responsible for for- 

Driver Services. These services provide the control struc- matting the layout of the outputted report, including 

ture and frameworic for the reporting system. standard headers, column headings, row headings, and 

o.^o,. „. . , other staUc report information. 

T r^""^ ^^'^''''^ f ^™ !r'^r^ ^^^^^ the information. This function is responsible for 

^uest is validated, the repo^rt build^JtJon is initi- ir,lS.^tlT£^s 

component of the client/seiver architecture. 

Report Build Services. These services are responsible for poimat the information. ITus function is responsible for 

coUectmg, processmg, formattmg. and wnung report fonnatting the collected information into the appiopri- 

mformation (for example, data, graphics, text). display fonnat based upon the report type L the 

Report Distribution Services. These services are respon- report distribution requirements, 

sible for printing, or otherwise distributing, the reports Output the report. This function initiates the report dis- 

to users tribution function in order to distribute the created 

Funcuons and Features of a Report Architecture 20 report to the specified devices (printers, didts, and so 

The report architecUire withm Environment Services sup- forth) and individuals, 

ports the generation and delivery of reports. AppKcations The process of coUecting, processing, formatting and 

request report services by sending a message to the reporting outputting report data can be accomplished in sever^ dif- 

framework. ferent ways. For example, one method is to create a program 

The following types of reports are supported by the 25 in C for each report format. Here, many aspects of report 

reporting apphcaUon framework: printin^^ch as page size, headings, footings, and printer 

Scheduled: Scheduled reports are generated based upon a control values — would have to be programmed in function 

time and/or date requirement. These reports typically calls to facilitate the report programming process. Informa- 

contain statistical information and are generated peri- tion access to files or the database would be through Infor- 

odically (invoices and bills, for example). 30 mation Access Services. 

On-demand: Some reports will be requested by users with Another option is to use a third-party report tool, such as 

specific parameters. The scheduling of these reports, SQR (Structured Query Report Writer) from SQL Sohi- 

the formatting, and/or the data requirements are not ^ods, SQR is a robust report generator designed to be used 

known before the request is made, so these factors must with SQL-based relational databases. SQR insulates the 

be handled at request time. 35 developer fi-om programming in a third generation language 

Eventndriven: This report type inchides reports whose providing a higher-level programming language. SQL 

generation is triggered based on a business or system q«enes (Information Access) are placed direcQy into the 

event. An example here would be a printed trade slip. program. 

Reporting AppHcation Framewoik ^^P"'^ Distribution (2904) 

FIG. 29 shows the major components of the reporting ^ requirement of the reporting application frame- 
application framework: ^ report distribution function. Once the report has 
Report Initiation (2900) generated, it must be distributed to the specified targets 
The report initiation function is the interface for reporting {^^^"^^ "^^)- ^P^^ distribution fimction will 
applications into the report architecture. The cHent initiates ^""^^^^ completed report files and route them to the appro- 
a report request to the report architecture by sending a P"!^*' .^'T?*^ withm the dicnt/server network, 
message to the report initiation fimction. The reM)onsibility ^ T)yically, a report distribution database is used to specify 
of report initiation is to receive, identify, and validate the the destmatio^ for each report supported by the report 
request and then trigger the report build process. The main ^^1^^^. The report distnbution database specifies 
components of reporting initiation are the following. "^^^'^^ when, how, and to whom to distribute the produced 
„ . .J , ^ report Specific destinations can include: printer(s), user(s). 
Receive identify, and validate a report request. The g^^j^ „chives (permanent storage), and/or spedfic 
Identification function determines general mfonnaUon display devices such as woAslations and terminals, 
about the request such as report type, requester, quan- Several addiUonal options exist for distributing reports 
Uty to be pnnted and requested tune. Based on the including timed reporting, mulUple copy distribuUon, and 
"'^'^ '^^^ of reports is ewmined in order to 55 ^port archiving. Also, a user interface fimction can be built 
gather additional report-specific infonnation and per- ^ open and browse report files 
form required validaUon routines for the report request. Cust„n, Reporting /^roaches 

After the report identification and validation functions jf ^ commercially-available reporting product can not 

have been sucoessMly completed, the reporUng pro- nieet your report requirements, you may have to consider a 

c^cai,contmue.lfajiyerroisareidentified.thereport «, custom approach. nO. 30 illustrates an example of how a 

initiation fiujction will return an enor message to the custom report architecture relates to a workstation plalfonn 

requester appbcaUon. technology architecture. 

Initiate report execution. The initiate report execution This custom report process is re^nsible for processing 

function processes the report profile and ^cific dis- all messages requesting generation, manipulation, or distri- 

tribution requirements and detennines the report to be 65 bution of reports. The following services are provided in an 

created. It then passes control to the report execution environment including a pair of workstations 3000 and a 

process. server 3002: 
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Report generation Report deletion proceeds as follows: 
Report deletion The report record is removed from the report status table. 
Report printing The report file is removed from disk. 
Report status maintenance . information requests are performed directly from 
Report generation is supported by an additional report the API using Information Access Services APIs. No inter- 
writer process that contains all application-defined report ^® ^^P°^ process is necessary, which results in 
writer modules. These modules contain the logic to produce improved performance, 
each of the report types that may be requested. The report Modules 

process receives generation requests and ensures that they module hierarchy for the custom report 

are forwarded to the report writer process at the current or process. The Figure shows the relationships between 

specified time. All report requests are processed in an modules, not their associated processing flows. It should be 

asynchronous manner (for example, service requesters do ^ identify the calling module and the called modules 

not wait for completion of report processing). ^® process. HG. 32 iUustrates the Architecture Manager 

FIG, 31 describes the relationships between the major ,5 ^^^^ "^^^^^ supports the report process, 

components of the report process 3100 and the report writer functions designed to support this process are: 

process 3102. Generate Report 

Design Approach Get Report Status 

For the report process in a client/server system, a set of Control Reports 

APIs is provided for use within application programs and 20 Request Report (b2402) 

within the application report writer modules. Each API Delete Renort n>24061 

requests a specific report service (generation, printing, or p. „ \^ (h24M\ 

deletion) which is performed by a report manager module. « ' f ^IJ'. ^ , , 

The report process maintains an internal database table, a ^^^'r"!''? ^^^""'^ mod^^c ^ called to request report 

report status tible, containing information about each repo^ 25 8^°^^^^^^^ 
that has been requested for generation, including: 

„ , tw^ Report name 

Requester ID „ 

Report parameters 

^ Report generation time (default is immediately) 

Date/time requested ^ Printer name. 

Status (requested, in process, complete, or error) The report name must be one of the defined application 

Report-specific parameters. report types. Valid report parameters vary dependii^ on the 

The requester ID, report name, and date/time arc used to report type. Reports may be requested for generation imme- 

uniquely identify the report. These values are passed to APIs diately or at a designated future time. All reports are written 

which request report status, print or delete a previously 35 to a reserved area on disk; however, specification of a printer 

generated report. causes the output to be printed as well as stored on the file 

All application-defined report writer modules invoke an system. 

API to update the report status table with a status of Get Report Status. The Get Report Status function 

"completed** after a report has been produced or with "error" retrieves status information about all reports that have been 

if the report cannot be generated. An API is also provided to 40 previously requested for generation by the calling process. 

print the report after the generation if specified in the Returned is a list containing the requested data as well as the 

original request number of reports found. 

Processed report records are removed from the table only Control Reports. The Control Reports function is respon- 

afler the output reports have been archived. Implementation sible for performing various operations on reports. The 

and frequency of this table cleanup is to be determined in 45 following services are provided: 

systems management design. Delete a report request and any associated output 

Report Process Flows Print a previously generated report. 

Report processing is message-driven. Each defined API Update report status. 

sends a unique message to the report process. The report In all cases, the report name is passed through an input 

process reads the messages firom a queue and invokes the 50 data block. For the print service, a printer name is passed. 

appropriate modules to handle each request. Subsequent For status update, the new status code is passed. 

process flows differ based upon the requested service. In the Request Report The Request Report function is respon- 

case of a report generation request, the process flow pro- sible for processing report request messages written to the 

ceeds as follows: report process queue. It creates a new entry in the report 

A record is added to the report status table. 55 status table with a status of "requested** and initiates the 

A message is sent to the report writer process for imme- ^P^""^ P">«^ fo"" immediate generation or sends a 

diate generation or to the event manager for generation message to the event manager for fiiture report generation. 

at a specified time (report scheduling). Delete Report. The Delete Report function is responsible 

T, - . T ,. ^ , , for removing a report from the Report Status list and 

The appropnate apphcation report writer module gener- j 1 ,u * j * . ni / c \ oiaiui* auu 

ates {he report, prints it if specified in tbe origind API ''"'^f ^^"^ ^fTE l^^'^ f^^^" . 

request, and updates the state in the report state table. ^^P^'^, ^^PJ"* a generated 

A request to prirt a report proceeds as follows: ""^^ °T ^ * specAed or default pnnter TTie report 

^ . . name and requesting process ID is passed to identify the 

The report status is retneved from the report status table. report 

The output file is located on disk and sent to the specified 65 Evaluation Criteria 

or default printer or the request is sent to tbe event There are two primary approaches to implementing a 

manager for report scheduling. reporting architecture: custom and package. Evaluating cus- 
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torn and package solutions involves both functional and 11. Section, Page, and Field Level Security: Defining secu- 

technical criteria. The following is a discussion of various rity at the report section, page, or field level would 

functional and technical criteria that should be considered provide greater flexibility in determining and implement- 

during the planning for a report architecture. Note that not ing report security. This is a desirable, though not 

all of the criteria may be required by any particular organi- 5 mandatory, requirement of the report architecture, 

zation. 12. Background Processing: The report architecture should 

Functional Criteria support the processing of reports in the backgroimd while 

1. Report Repository: The report architecture should work the application works in the foreground during online 
with, and support maintenance of, a report repository on hours. In other words, processing of reports should not 
the platforms within the client/server architecture. The negatively affect online response times, or tie up the 
report repository contains the detailed definitions of the user's workstation. 

reports. 13. Automatic Report Addressing: The report architecture 

2. Workgroup Report Support The report architecture should provide a "humanly intelligible" address for all 
should work with and support distribution of reports distributed reports. The address may be used by a print 
generated on the workgroup server. site operator, LAN administrator, or other personnel to 

3. On-Demand Reports: The report architecture must sup- manually sort printed output (if required). This criterion 
port distribution of reports requested by users on demaiMl. can be satisfied by automatic creation of banner pages or 
Typically, these reports will not have a set schedule or other means. 

fiequency for distribution. The report architecture must 1^- Delivery Cbsting: To provide sufficient information to 

support distribution of these reports without the require- acddenUUy downloading or printing very 

ment of manual or user intervention (subsequent to initial ^ reports during peak usage hours, a distribution 

set up and conversion). costing function can be useful. This function would warn 

4. Scheduled Reports: The report architecture must support °^ "^^^^ overload the network or a 
distribution of regularly scheduled reports. Typically, P"°^^^- ™^ costing function might provide recipients 
these reports will have a set schedule and frequency for * ^^^^ estimate of the amount of time that distri- 
distribution. The report distribution package must support ^ Fmally, during the onUne day, the 
distribution of these reports without the requirement of delivery costing mechanism might disallow transmission 
manual or user intervention (subsequent to set up and °^ reports that exceed a predetermined cost, 
conversion). ^^^pl^ Destinations: The report architecture should 

5. Online Preview: The report architecture should allow support distribution of a single report to single or multiple 
preview of reports online fiom a user's intelligent work- ^ destinations. 

station prior to actual distribution. Ideally, the report Destmation Rationalization: For some systems, it is 

architecture itself would provide support for online pre- possible that multiple copies of a report will be sent to the 

view of reports through software located on the intelligent site— to several different users, for example. In 

workstation. cases, it is highly desirable to have the report 

6. Graphical User Interface: The architecture should provide architecture recognize these situations whenever possible 
users with a graphical user interface. distribute the specified report only once. 

7. Bilingual Support: For companies where two or more Automatic Printing: The report architecture should pro- 
languages are used, the report architecture must provide a automatic print capabilities. Once a report has been 
multi-national user interface. (Note that large report runs distributed for printing (either through a "push" distribu- 
targeted for multiple users may require the abiHty to ^ scheduling mechanism or through a ^'puU" user 
change languages during the report.) request) no further user or operations personnel involve- 

8. Basic Preview Functions: The report architecture should ^^^^ ^ necessary to print the report at the 
support basic preview functions. These include: specified location. 

ScroUing up and down. ^^^P^^ Destinations: The report architecture 

Scrolline left and riehl ^^^^^ support distribution of reports for printing at 

Aj. •* ju - r 1. «. centralized, remote, or local print sites without user or 

Advancmg to end or begmmng of report without scroUmg operations personnel intervention, 

o ,!^^Sh mlermediate pages. . ^ . 19. Variable Printer Types: Printing on multiple types of 

9. Advanced Preview FuncUons: In addiUon to the basic ^^^^^ molu^g fine, impact, and laser printers, should 
preview ftmcUons hsted previously, certam advanced 5^ be supported. This should not require user intervention- 
preview functions may also be necessary: ^ ^^^^^ ^^^^ 

Page mdexmg (allows users to jump to specific report target printer. Ideally, the report architecture would 

P^^^^y default this information from the user's profile or the 

Section indexing (allows users to jump to specific report default printer defined in the local operating system. This 

sections). 55 criterion requires that the report architecture support 

Search capabihties (allows users to search report for several print mechanisms, such as postscript drivers and 

occurrence of a specific data stream). host/mainframe protocols (for example. Advanced Func- 

10. Report Level Security: Reports may occasionally con- tion Printing [AFP]). 

tain sensitive information. It is therefore important that 20. Variable Printer Destinations: The report architecture 

access to certain reports be restricted to authorized users. 60 should default the destination printer for a specific report 

The report architecture should provide a mechanism for (from the user's profile or operating system parameters), 

implementing report level security. Tbis security must be Additionally, the architecture should allow the user to 

in place on all platforms with the client/server architec- change the printer ^dfied. Validation of the print des- 

turc. At the woricgroup level, the security may consist of tination also ^ould be included. 

downloading sensitive report files to a secure directory, 65 21. Special Forms Printing: The report architecture should 

and having the LAN administrator release the report as support distribution of "regular^ reports and special forms 

appropriate . reports. 
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22. Font Support: Some reports may be printed on laser 
printers and/or may support electronic forms text (i.e., 
including the forms text in the report dataset as opposed 
to printing the report dataset on a pre-printed form). The 
architecture diould allow multiple fonts to be specified. 

23. Report Archival: The report architecture should provide 
and/or facilitate archival or disposition of report datasets. 
Ideally, the architecture would permit definition of reten- 
tion periods and disposition requirements. 

24. Report Download: The report architecture should allow 
distribution of the information contained in a report 
dataset to a user's intelligent workstation. Hie informa- 
tion should be in a form that can be imported to a local 
word processing software, decision support software 
package, or other appropriate application. 

25. Application Transparency: It is desirable for the report 
architecture to appear to the users as if it were part of the 
overall application. This does not necessarily mean that 
the architecture must integrate seamlessly with the appli- 
cation; a message interface between the systems might be 
acceptable. 

26. Selective Printing: It would be desirable for the report 
architecture to provide users with the ability to print only 
selected pages or sections of the report. This should 
reduce paper usage, while still allowing users to obtain a 
hard copy of the information as required. 

27. Print Job Restart: It would be desirable if the report 
architecture allowed a print job to be restarted from the 
point of failure rather than having to reprint the entire 
report. This of particular concern for very large reports. 

Technical Criteria 

The following is a list of technical criteria that should be 
considered during the planning for a report architecture: 

1. Platform Compatibility: The report architecture must be 
compatible with the platform architecture. It also ^ould 
be compatible with local area networks and standalone 
workstation technology specified in the platform archi- 
tectm-e. 

2. Wide Area Network Compatibility: Most systems will 
include support for WAN communication, so the report 40 
architecture should be compatible with this environment. 

3. Technology Standards: The report architecture should be 
compliant with existing formal and de facto standards (for 
example, SQL Database Language, COBOL Program- 
ming Language, C Programming Language). 

4. External User Directory: The report architecture should 
make use of an external user directory of preferences and 
locations. 

5. Data Compression in Report Repository: To reduce the 
storage requirements for the report repository, it is also 
desirable for the report architecture to support data com- 
pression in the repository. 

6. Code Page Compatibility: Code page compatibility must 
be considered when translating diaracters to ASQI. 

Workflow Services (2890) 

Woricflow services control and coordinate the tasks that 
must be completed in order to process a business event. For 
example, at XYZ Savings and Loan, in order to receive a 
promotion, you must complete an essay explaining why you 
should be promoted. This essay and your personnel file must 
be routed to numerous individuals who must review the 
material and approve your promotion. Workflow services 
coordinate the collection and routing of your essay and your 
personnel file. 

Workflow enables tasks within a business process to be 
passed among the appropriate participants, in the correct 
sequence, and facilitates their completion within set times 
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and budgets. Task definition includes the actions required as 
well as work folders containing forms, documents, images 
and transactions. It uses business process rules, routing 
information, role definitions and queues. Workflow func- 
tionality is crucial for the customer service and engineering 
applications to automate the business value chains, and 
monitor and control the sequence of work electronically. 

The business processes can be of a repetitive nature, eg 
automatically routing and controlling the review of a work 
plan through the approval stages. These are called produc- 
tion workflows. Conversely it can be an ad hoc process, eg 
generating and delivering a work order for a special meter 
reading to a meter reader who is available to perform the 
task. In production workflows the processes are predefined, 
whereas ad Ihx; workflows are created only for a specific 
nonrecurrent situation. Often it is difficult to determine how 
much ad hoc fiinctionality that needs to be provided. An 
overly strict production workflow may not support necessary 
special cases that must be handled in an ad hoc fasion. 

Workflow provides a mechanism to define, monitor and 
control the sequence of work electronically. These services 
are typically provided by the server as they often coordinate 
activities between multiple users on multiple computers. 

The foUowing are some of the architectural and integra- 
tion issues that must be addressed: 
Process integration 
The workflow system must achieve a seamless integra- 
tion of multiple processes. The workflow system 
must control the business process, eg it should be 
able to open a word processor with the relevant data 
coming from a previous business process; 
Infrastructure integration from PC to mainframe 

The ability to interface with the host-based hardware, 
system software, and database management systems 
is critical. This is essential because the workflow 
system is located between the client-based and host- 
based processes^ ie it can initiate client-based as well 
as host-based applications; 
LAN and WAN coimectivity 

Connectivity must include all sites for the supported 
processes, enabling a large number and variety of 
users to use the workflow system, and thus to execute 
the business process; 
Integration of peripherals 

The workflow system should support many different 
types of printers, modems, fax machines, scaimers, 
and pagers. This is especially important because of 
the diversity of the users that wiU be involved, from 
field crew to managers, each with their own needs 
and preferences; and 
Integration with workflow-participating applications 
The key to the efficiency of the workflow system is its 
capability to integrate with office automation, 
imaging, electronic mail, and legacy applications. 
Workflow can be fiirther divided into the following com- 
ponents: 

Role management 

Role management ie provides for the assignment of 
tasks to roles which can then be mapped to individu- 
als. 

A role defines responsibilities which are required in 
completing a business process. A business worker 
must be able to route documents and folders to a role, 
independent of the specific person, or process fiUing 
that role. For example, a request is routed to a 
supervisor role or to Purchasing, rather than to 
"Mary" or "Tom." If objects are routed to Mary and 
Mary leaves the company or is reassigned, a new 
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recipient under a new condition would have to be istration tools. Some of the areas for monitoring for 

added to an old event. Roles are also important when improvement are employee productivity, process 

a number of different people have the authority to do performance, and forecasting/scheduling. Where any form 

the same work, such as claims adjusters; just assign of customer service is involved, features like status reports 

the request to the next available person. In addition, 5 on individual cases can sharpen customer response times 

a process or agent can assume a role; it doesn't need performance monitoring of groups and individuals can 

h HH^"^ i 'i r Services provide help quality improvement and efficiency exercises. Note that 

this additional level of directory indirection. ^p^^s and reporting does not necessarily mean paper 

Route management reports that are distributed in a traditional manner, it can 

Route management enables the routing of tasks to the jo mean electronic messages or even triggeis based on specific 

next role, which can be done in the following ways: events. 

Serial— the tasks are sequentiaUy performed; Are cooperative applications present? 

Parallel— the work is divided among different play- Workflow management is frequently required in coopera- 

. . . tive applications because the users are generally 

CondiUonal— routmg is based upon certain condi- 15 professionals, the flow of work in the organization is fre- 

tons; and quently highly variable, the application units of work (legal 

Ad hoc— work which is not part of a predefined case, sales order) are processed for long periods of elapsed 

„. ,^^°^^* . . time, and work often moves from one processing site to 

Workflow rouUng services route * Voik" to the appro- another. As data and application logic are spHt, better control 

pnate workflow queues. When an application com- 20 is needed to track processing/data status across location, 

pletes processmg a task, it uses these services to will there be business process re-engineering? 

route the work-in-progress to the next required task Workflow is a logical complement to BPR and the trend 

or tasks and, m some cases, notify interested parties is moving toward using workflow software to rc-«ngineer 

of the resulting work queue changes. new business processes on a workgroup or project basis. 

The automatic movement of information and control 25 Is the business process weU defined? 

from one workflow step to another requires work if rules or conditions can be identified which define the 

profiles that describe the task relationships for com- business process, with few exception conditions, workflow 

pletmg vanous business processes. The concept of tools can then automate areas such as information routing. 

Integrated Performance Support can be exhfljited by task processing, and work-in-process reporting, 

providmg user access to these work profiles. Such 30 Are fixed delays or deadlines involved? 

access can be solely informational— to aUow the user Workflow has been used to regulate ctelays and deadlines 

to understand the relationship between tasks, or s^ch as those associated with government regulations, con- 

identify which tasks need to be completed for a tractual obUgations, accounting periods, customer service, 

particular work flow-^r navigational-^o allow the and sales lead follow-up. Tjrpical workflow goals are shorter 

user to move between tasks. 35 time to market and quicker response times. 

Route Management Services also support the routing Are multiple people involved in the business process? 
and delivery of necessary information (e.g.. Workflow co-ordinates cross-functional, cross- 
documents, data, forms, apphcations, etc.) to the departmentalworkactivitiesandpromotesaccountability.lt 
next step m the work flow as needed. also enables dynamic redistribution and reprioritization of 
Rule Management 40 work. 

A business process workflow is typicaUy composed of Is there a need for work scheduling? 

many different roles and routes. Decisions must be Workflow management can be extended to automate work 

made as to what to route to which role, and when. scheduling. A system may be able to do as good a job, or 

Rule Management Services support the routing of better, in scheduling a users work. This might be due to a 

workflow activities by providing the intelligence 45 very large amount of work to be assigned to a large pool, a 

necessary to determine which routes are appropriate complex method of assigning priorities, an extremely 

given the state of a given process and knowledge of dynamic environment, or some other reason. Another advan- 

tbe organization's workflow processing rules. Rule tage to work scheduling is that die system can initiate some 

Management Services are typically implemented needed activity automatically for the user in anticipation of 

through easily maintainable tables or rule bases 50 the next task, 

which define the possible flows for a business event. Dq integration issues exist? 

Queue Management It is important to determine how well the workflow 

These services provide access to the workflow queues system integrates with host-based hardware, system 

which are used to schedule work. In order to perfoma software, database management systems, and communica- 

workload analysis or to create "to do lists" for users, 55 tion networks. Examples of items to consider include 

an application may query these queues based on E-mail, database, GUI tool, PC applications, other office 

various criteria (a business event, status, assigned systems, and business applications, 

user, etc.). In addition, manipulation services are How scaleable is the product? 

provided to aUow queue entries to be modified. Number of woricers the product could reliably support in 
Workflow services allow users and management to 60 a production environment. Two major product factors char- 
monitor and access workflow queue information and acterize scalability: (1) Platform alternatives (hardware and 
to invoke applications directly. operating system); and (2) Message-based architecture 
Is there a need for reporting and management facilities? (relying on specific mail systems for much of the 
Typical workflow application requirements arc better gen- functionality) versus Database-based, 
eral management control and better management of change. 65 What is the nature of the workflow? 
Proactive system action, audit trails and system administra- How an organization approaches the management of its 
tion features like work queue reporting are important admin- workflow will determine which workflow management tools 
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arc appropriate to the organization. In general, there are 
three types of workflow, production, collaborative, and ad 
hoc. A production environment involves high transaction 
rates and thousands of documents in which the rules for a 
certain document can be defined for most of the time. 
Examples include accounts payable, insurance claims 
processing, and loan processing. A collaborative environ- 
ment involves multiple departments viewing a single docu- 
ment with typically less number of documents than in the 
production enviroament. One example is a sales order. Ad 
hoc workflows arise from the specific temporary needs of a 
project team whose members become active and inactive 
depending on their function within the group. 

What is the relationship between the workflow and imag- 
ing components? 

It may be important to determine whether or not the 
products work routing fiioction is integrated and inseparable 
from document storage and retrieval functions. 

What are the necessary functions and features? 

Issues to consider include the following: (1) samples and 
assists that are available to the developer; (2) existence of a 
scripting or programming language; (3) granularity of the 
security, or in other words, at what levels can security be 
added; (4) freedom of choosing productivity applications; 
(5) existence of aggregate functions which allow for analysis 
of the workflow efficiency; (6) existence/need for Business 
Processing Re-engineering tools. 

How stable is the vendor? 

One should consider the leadership and size characteris- 
tics of the products vendor compared to the workflow 
software marketplace. Another consideration is whether the 
vendor is a member of Workflow Management Coalition. 
This coalition is beginning to have a bigger impact on the 
direction of vendors worlffiow management products. 

How mature is the product? 

One should consider the age, release, and installed base of 
the product. 

How flexible is the product? 

A product should be able to support changing workflows 
at various levels of detail. 
Business Logic 1022, 1024 

The execution architecture services are all generalized 
services designed to support the applications Business 
Logic. How Business Logic is to be organized is not within 
the scope of the execution architecture and must be deter- 
mined based upon the characteristics of the application 
system to be developed. This section is intended to serve as 
a reminder of the importance of consciously designing a 
structurc for Business Logic which helps to isolate the 
impacts of change, and to point out that the underlying 
Netcentric architecture is particularly weU suited for 
enabling the packaging of Business Logic as components. 

Business Logic is the core of any application, providing 
the expression of business mles and procedures (e.g., the 
steps and rules that govern how a sales order is ^IfiUed). As 
such, the Business Logic includes the control stmcture that 
specifies the flow for processing business events and user 
requests. There are many ways in which to organize Busi- 
ness Logic, including: rules-based, object-oriented, 
components, structured programming, etc. however each of 
these techniques include, although perhaps not by name, the 
concepts of: Interface, Application Logic, and Data Abstrac- 
tion. FIG. 33 depicts the various components of the Business 
Logic portion of the Netcentric Architecture Framework. 
Interface Logic (3302) 

Interface logic interprets and maps the actions of users 
into business logic processing activities. With the assistance 
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of Presentation Services, Interface logic provides the linkage 
that allows users to control the flow of processing within the 
application. 

Application Logic (b2504) 
5 Application Logic is the expression of business rules and 
procedures (e.g., the steps and rules that govern how a sales 
order is fidfilled). As such, the ;^>plication Logic includes 
the control structure that specifies the flow for processing for 
business events and user requests. The isolation of control 

10 logic facilitates change and adaptability of the application to 
changing business processing flows. 
DaU Abstraction (b2506) 

Information Access Services isolate the Business Logic 
from the technical specifics of how information is stored 

15 (e.g., location transparency, RDBMS syntax, etc.). Data 
Abstraction provides the application with a more logical 
view of information, further insulating the application from 
physical information storage consideratioiss. 
The developers of business logic should be shielded from 

20 the details and complexity of other architecture services 
(e.g., information services, component services), and other 
business logic for that matter. 

It is important to decide whether the business logic wiU be 
separate from the presentation logic and the database access 

25 logic. Today separation of busiiKss logic into its own tier is 
oflen done using an application server. In this type of an 
environment, although some business rules such as field 
validation might still be tightly coupled with the presenta- 
tion logic, the majority of business logic is separate, usually 

30 residing on the server. It is also important to decide whether 
the business logic should be packaged as components in 
order to maximize software re-use and to streamline soft- 
ware distribution. 

Another factor to consider is how the business logic is 

35 distributed between the cHent and the server(s) — ^where the 
business logic is stored and where the business logic is 
located when the application is being executed. There are 
many ways to distribute business logic: (1) business logic 
can be stored on the server(s) and executed on the server(s); 

40 (2) business logic can be stored on the server(s) and 
executed on the chent; (3) business logic can be stored and 
executed on the client; (4) some business logic can be stored 
and executed on the server(s) and some business logic can 
be stored and executed on the client; etc. 

45 Having the business logic stored on the server enables 
developers to centrally maintain application code; thereby 
eliminating the need to distribute software to client 
machines when changes to the business logic occur. If aU the 
business logic executes on the server, then the application on 

50 the client will make requests to the server whenever it needs 
to execute a business function. This could increase network 
traffic, which may degrade application performance. On the 
other hand, having the business logic execute on the client, 
may require longer load times when the application is 

55 initiaUy launched. However, once the application is loaded, 
most processing is done on the client until synchronization 
with the server is needed. This type of an architecture might 
introduce complexities into the application that deal with the 
sharing of and reliance on central data across many users. 

60 If the business logic is stored and executed on the client, 
software distribution options must be considered. UsuaUy 
the most expensive option is to have a system administrator 
or the user physically install new applications and update 
existing applications on each client machine. Another option 

65 is to use a tool that performs automatic software distribution 
functions. However, this option usuaUy requires the soft- 
ware distribution tool to be loaded first on each client 
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madiine. Another option is to package the application into Currently, Internet applications house the majority of the 

ActiveX controls, utilizing the automatic installAipdate business processing logic on the server, supporting the 

capabilities available with ActiveX controls — ^if the appli- thin-client model. However, as technology evolves, this 

cation is launched from a Web browser. balance is beginning to shift, allowing biisiness logic code 
Currently, Internet applications house the majority of the 5 bundled into components to be either downloaded at nintime 

business processing logic on the server, supporting the permanently stored on the client machine. Today, client 

thin-client model. However, as technology evolves, this business logic is supported through the use of Java 

balance is beginning to shift, allowing business logic code applets, JavaBeans, Plug-ins and JavaScript from Sunl- 

bundled into components to be either downloaded at runtime Netscape and ActiveX controls and VBScript from 
or permanently stored on the client machine. Today, client lo Microsoft, 

side business logic is supported through the use of Java Patterns 

applets, JavaBeans, Plug-ins and JavaScript from Sun/ Overview of Patterns 

Netscape and ActiveX controls and VBScript from Introducing Patterns 

Microsoft. The goal of patterns within the software community is to 
The developers of business logic should be shielded from 15 create a body of literature to help software developers 
the details and complexity of other architecture services resolve common difficult problems encountered throughout 
(e.g., information services, component services), and other ^ software engineering and development. Patterns help 
business logic for that matter. create a shared language for communicating insight ai^ 
It is important to decide whether the business logic wiU be experience about these problems and their solutions. For- 
separate from the presentation logic and the database access 20 ™ally codifying these solutions and their relationships lets 
logic. Today separation of business logic into its own tier is us successfully capture the body of knowledge which com- 
often done using an application server. In this type of an prises one's understanding of good architectures that meet 
environment, although some business rules such as field needs of their users. Forming a common pattern lan- 
validation might still be tightly coupled with the presenta- guage for conveying the structures and mechanisms of 
tion logic, the majority of business logic is separate, usually 25 architectures allows us to intelligibly reason about them. The 
residing on the server. It is also important to decide whether primary focus is not so much on technology as it is on 
the business logic should be packaged as components in creating a culture to document and support sound engineer- 
order to maximize software re-use and to streamline soft- architecture and design, 
ware distribution. What is a Pattern? 

Another factor to consider is how the business logic is 30 ^ pattern is a named nugget of insight that conveys the 
distributed between the client and the scrver(s) — ^where the essence of a proven solution to a recurring problem within 
business logic is stored and where the business logic is * certain context amidst competing concerns. Patterns are a 
located when the application is being executed. There are formal way to document codified knowledge, or rules- 
many ways to distribute business logic: (1) business logic of-thumb. 

can be stored on the servei(s) and executed on the servei(s); 35 Patterns represent the codified work and thinking of our 

(2) business logic can be stored on the server(s) and object technology experts. While experts generally rely on 

executed on the client; (3) business logic can be stored and mental recall or rules-of-thumb to apply informal patterns as 

executed on the client; (4) some business logic can be stored opportunities are presented, the formalization of the patterns 

and executed on the server(s) and some business logic can approach allows uniform documentation and transfer of 

be stored and executed on the client; etc. 40 expert knowledge. 

Having the business logic stored on the server enables Patterns are not unique to object technology or even 

developers to centrally maintain application code; thereby software development, having been invented by Christopher 

eliminating the need to distribute software to client Alexander, a building architect. However, they have not 

machines when changes to the business logic occur. If all the applied to other information technology development 

business logic executes on the server, then the application on 45 techniques. Thus, they are an exclusive feature of object 

the client will make requests to the server whenever it needs technology. Fiirtbermore, patterns are becoming widely 

to execute a business frmction. This could increase network accepted by the worldwide object community as an impor- 

traffic, whidi may degrade application performance. On the element in successfully rolling out the technology, and 

other hand, having the business logic execute on the client, enabling the maturation of software development as an 

may require longer load times when the application is 50 engineering process. 

initially launched. However, once the application is loaded. Patterns are usually concerned with some kind of archi- 

most processing is done on the client until synchronization tecture or organization of constituent parts to produce a 

with the server is needed. This type of an architecture might greater whole. Richard Gabriel, author of Patterns of Soft- 

introduce complexities into the application that deal with the ^are: Tales From the Software Community, provides a clear 

sharing of and reliance on central data across many users. 55 concise definition of the term pattern: 

If the business logic is stored and executed on thie client. Each pattern is a three-part rule, which expresses a 

software distribution options must be considered. Usually relation between a certain context, a certain system of 

the most expensive option is to have a system administrator forces which occurs repeatedly in that context, and a 

or the user physically install new applications and update certain software configuration which allows these 

existing appUcations on each client machine. Another option 60 forces to resolve themselves. 

is to use a tool that performs automatic software distribution As an element in the world, each pattern is a relationship 

fimctions. However, this option usually requires the soft- between a certain context, a certain system of forces 

ware distribution tool to be loaded first on each client which occurs repeatedly in that context, and a certain 

machine. Another option is to package the application into spatial configuration which allows these forces to 

ActiveX controls, utilizing the automatic installAipdate 65 resolve themselves. 

capabilities available with ActiveX controls— if the appli- As an element of language, a pattern is an instruction, 

cation is launched from a Web browser. which shows how this spatial configuration can be' 
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used, over and over again, to resolve the given system Management Considerations section of the Introduction to 

of forces, wherever the context makes it relevant. Component-Based Development uses the Business Integra- 

The pattern is, in short, at the same lime a thing, which tio° (BI) Model to discuss the impact of OO, including: 

happens in the world, and the rule which tells us how Strategy and planning with a long-term view towards 

to create that thing, and when one must create it. It is 5 building reusable, enterprise software assets 

bothaprocessandathingiboaiad^riptionofatto^ Technology and architecture approaches for building 

which IS alive and a descnpuon of the process which cohesive, loosely coupled systems that provide long 

may generate that thmg. flexibility. 

In 5<)^/iePfl«ems, Jim Coplien writes, a good pattern p,^.... .u ♦ ue. i • • ... 
may do the following: lo Processes that shift analysis/design techniques finom 

T* 1 1.1 . . . functional, procedural decomposition to business pro- 

It solves a problem: Patterns capture solutions, not just cess modeUng. TTiese tech Jques are then used to 

abstract principles or strategies. decompose the system into domain objects and pro- 

It IS a proven concept: Patterns capture solutions with a cesses. 

track record, not theories or speculation. a ^ • *• ^ . • . . • 

_ , . . , ^ . ^ 15 People and organization strategies that emphasize greater 

The soluuon isn t obvious: Many problem-solving tech- ^dalization of skills within stmctures that support 

niques (such as software design paradigms or methods) inter-team collaboration. 

try to derive solutions fiom first principles. The best Balancing TradeoflFs is Key to y^lying Components for 

patterns generate a solution to a problem indirectly— a Mission-critical Systems 

necessary approach for the most diflacult problems of ^ Tradeofis are an important theme. Experience with large, 
design. mission-critical systems has shown that the most complex 
It describes a relationship: Patterns don't just describe issues require strategic tradeoff between quality, cost, and 
modules, but describe deeper system structures and time. These tradeoflk usually involve interdependent con- 
mechanisms, siderations between strategy, technology, process, and 
Ibe pattern has a significant human component .... All 25 people. See FIG. 34 which illustrates a relationship between 
software serves human comfort or quality of life; the major themes. For example, how should an architecture be 
best patterns explicitly appeal to aesthetics and utility. tailored to effectively support a specific methodology, for a 
Component-based Development given organization's skill set? Competing tensions also 
Introduction to Component Based Development cloud decisions at a more detailed level For example, how 
Component systems model — how the business works 30 should an architecture be customized to better support 
Component-orientation is a strategic technology that may performance, at the potential cost of increased coupling 
significantly impact a user's practice and clients. Cbmpo- between components? 

nent technologies are a natural evolution firom object- Many of these considerations have been addressed over 

oriented systems providing a more mature way of packaging last few years. Most publi^ed literature continues to 
reusable software units. Object-oriented systems more 35 focus on narrow technology issues, such as programming 

closely support business integration framework for solution techniques or generic methodologies, such as analysis and 

delivery by shifting design focus away from an underlying design approaches or notation. Still, a growing number of 

technology toward a company's business conduct and fine- publications and vendor strategies attack the enterprise 

tional behaviors. Business entities are represented as objects, needs within on-line netcentric execution models. Real- 

which package data and functional behavior. This is in 40 world, client solutions involve making pragmatic decisions, 

distinct contrast to traditional development approaches that ^ which compromise occurs at the intersection of the four 

maintain a ubiquitous split between functional behaviors and major OO themes. Experience with many component client 

data. projects in diverse industries uniquely positions a user to 

Object-orientation has accelerated into the take-up curve. effectively address these complexities. 

All of the major commercial component models are object- 45 Management Considerations Overview 

oriented. In addition, all of the major vendors have adopted The Management Considerations section discusses the 

the "Unified Modeling Language" (UML) as a standard ^tey benefits, risks, and issues introduced by a component 

notation for describing object models. A tremendous reser- engagement. Key topics include: 

voir of knowledge capital, practice aids and starter kits Managing risk in balancing tradeofife between strategy, 

related to object and component technology can be found on 50 people, process, and technology 

the Knowledge Exchange. . Considering issues related to configuration management. 

More and more, users are askmg for assistance to deploy testing, and performance of objart systems 

INetcentnc eCommerce applications based on components. * j ^ • l , 

These appHcations are frequenUy based on object-rented Addressing the component development learning curve 

languages like Java, \^al Basic and C++. 55 Differences between development architecture consider- 

Objects are an easy metaphor to understand and manage. ations leveraging the advantages of a component indus- 

There are still substantial risks involved, particularly ^* 

because component- and object-orientation has a pervasive ^® Management Considerations section also address 

impact on areas as broad as analysis and design, planning, issues not umque to Component technology, including: 

and development tools. 60 Estimating, planning, and managing iteration 

Component-based Overview Organizing and managing to achieve reuse of both archi- 

Component Technology Impacts Most Aspects of Develop- tecture and business logic 

™ent Neteentric Patterns Overview 

Component and object technology impacts most aspects Netcentric Patterns Focus on >^lication Frameworks 

of software development and management. Component 65 Netcentric Patterns focus on how to design and leverage 

technology is a new technology and a driving influence in appKcation firameworks, which are pieces of reusable appU- 

the evolution of object-oriented (OO) methodologies. The cation architecture that provide a highly configurable, flex- 
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ible and maintainable system. They are aligned with SAF trated in FIG. 35. Some of them — typically designers — take 
and/or DAP service layers. Alignment with SAF and/or a logical per^ctive. They view components as a means for 
DAF makes the patterns easier to grasp the context for which modeling real-world concepts in the business domain. These 
they are solving problems. are Business Components. Others— typicaUy developers- 
There was no mandate to express mjplementation within 5 take a physical perspective. Tliey view components as 
any given particular 00 language. Java and Visual Basic independent pieces of software, or application building 
have increased m popularity over the last few years and C++ blocks, that implement those real-world business concepts 
^tinues to be a solid foundaUon on which to build many ji^^ ^ Partitioned Business Components. Develo^rs 
types apphcaUons. Id addition, some implementahons chose „t„ u * *i- * n j n • ^ 
thrdesi^ syntax of UML. Om should see the value of the ^Il^'l'^™ T ^.^^^"".^ Components can 
pattern regardless of the implementation personality. '° bmit from other independent pieces of software that 
Nowhere has this been more strongly demonstrated than in P^"^^^ funcUonality that is generally useful across a wide 
the Eagle Starter Kits. Here, the Eagle Architecture Speci- applications. These are Engineenng Components, 
fication has been documented in patterns and implemented . To use an analogy, the designer of a PC workstation would 
in Msual Basic, Java, C++ and a host of execution environ- initially think in terms of logical components such as Disk 
ments within these language offerings. The power is in the Storage, Memory, Display, etc. These are analogous to 
reusable design patterns. Business Components. At some point in the design process. 

For a high-level description of the context for the patterns however, this thinking must become more precise. For 

within a service layer of SAF and/or DAF, click the title of example, Disk Storage might become a Hard Disk Drive and 

the section. Please refer to the SAF and/or DAF for more Disk Controller Card. These are analogous to Partitioned 

detailed descriptions of the service layers. From the Frame- 20 Business Components. And finally, the designer might use 

works Main Page, under Framework Extensions, the "Com- generic parts in the design of the Disk Controller Card, such 

ponent Technology Extension" describes, in the context of as Memory Chips for cache. Bus Adapters, etc. These are 

the Netcentric Architecture framework, the additional, analogous to Engineering Components, 

specialized, architecture services that are required when Establishing one definition to satisfy all of these perspec- 

building a system using component technologies. 25 lives is certainly not required to be successful with compo- 

^^roach ' nents. What's more important is to recognize the different 

Over the past years, component-based development has per^ctives and to understand when it's appropriate to talk 

become an important, but often-misunderstood concept in about a particular type of component. Hence, multiple 

the IT world. Components in themselves don't guarantee definitions, one for each type of component: 

successful business applications, but coupled with a proven 30 Business Components represent real-world concepts in 

methodology and continuous technological advancements, the business domain. They encapsulate everything about 

they make it possible to realize a number of important those concepts including name, purpose, knowledge, 

benefits such as flexibility, adaptability, maintainability, behavior, and all other intelligence. Examples include: 

reusability, integration readiness, interoperability, and seal- Customer, Product, Order, Inventory, Pricing, Credit Check, 

ability, 35 Billing, and Fraud Analysis. One might think of a Business 

Components have been around for a long time. The Component as a depiction or portrait of a particular business 

wheels on an ancient Roman chariot were certainly compo- concept, and as a whole, the Business Component Model is 

nents. When the local chariot maker invented a new wheel a depiction or portrait of the entire business. It's also 

(one that promised greater speeds and improved reliability important to note that although this begins the pmcess of 

on a wider variety of terrain), chariot owners would replace 40 defining the application architecture for a set of desired 

their womK)ut, inefficient, and out-dated wheels with the business capabilities, the applicability of the Business Com- 

new ones, but only if the new ones offered, at a minimum, ponent Model extends beyond application building, 

the same function (i.e., rolling) through the same interface Whereas Business Components model real-world con- 

(i.e., the connection between the wheel and the chariot). cepts in the business domain. Partitioned Business Compo- 

Today components are used to build everything from cars 45 nents implement those concepts in a particular environment, 

to computers. In electronics, for example, they have led to They are the physical building blocks used in the assembly 

the proliferation of product features, disposability, of applications. As independent pieces of software, they 

miniaturization, product selection, price reduction, and Stan- encapsulate business data and operations, and they fulfill 

dard interfaces — all good for the consumer. This example distinct business services tiirough well-defined interfaces, 

also draws attention to some of the challenges that accom- 50 Business Components are transformed into Partitioned Busi- 

pany components: setting standards, determining the right ness Components based on the realities of the technical 

components, the need to change standard interfaces based on environment: distribufion requirements, legacy integration, 

new requirements, and the legal and commercial structure performance constraints, existing components^ and more, 

for selling components. For example, a project team might design an Order Business 

Throughout the industry the word "component" is used 55 Component to represent customer demand for one or more 

broadly and often loosely. Components come in a wide products, but when it's time to implement this concept in a 

variety of shapes and sizes. For example: JavaBeans, particular chent/server environment, it may be necessary to 

ActiveX controls, and COM objects. And more generically: partition the Order Business Component into the Order 

application, architecture, development, engineering, Web, Entry component on the client and the Order Management 

server, and business components. 60 component on the server. These are Partitioned Business 

Many industry experts have attempted to define "compo- Components, 
nent." Unfortunately, many of these definitions are too Engineering Components are independent pieces of soft- 
abstract, too academic, or too specialized to be useful. Yet ware that provide functionafity that is generally usefiil 
below the surface of these definitions is some real business across a range of applications. They come in all shapes and 
value for organizations. 65 sizes, and they are typically packaged as black box capa- 

Experience has shown that it's quite common for people bilities with well-defined interfaces. They are the physical 

to view components from different perspectives, as iUus- building blocks used in the assembly of Partitioned Business 
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ComponeDts. Examples include: a workflow engine, a Java- In Capability Release Build and Test, Partitioned Business 

Bean that encapsulates a reusable concept like address or Components are built and tested. The build process varies 

monetary unit, a complex widget that allows users to edit a depending upon the technology chosen to build the internal 

list of order lines, a group of objects responsible for workings of each Partitioned Business Component Among 

persistence, a JavaBean that sorts a collection of objects, and 5 the many tests that arc performed during this stage, the 

a simple list box coded as an ActiveX control. component, assembly, and performance tests are impacted 

Components are useful throughout the development pro- ^ ^^X^^ development. A component test 

cess. As a design artifact, early in the process. Business addresses a Partitioned Business Component as a single unit 

Components provide an underlying logical framework for ^^^^^ interfaces and its internal workings, while an 
ensuring flexibility, adaptability, maintainability, and reus- lo ?fembly test addresses the mteractions between Partitioned 

ability. They serve to break down large, complex problems Components by testing broader scenarios. The 

into smaller, coherent elements. TTiey also model the busi- P^^^""^^ ^ ^ ""Pf^ted pnmanly by the techniques 

ness in terms of the real-world conc^epts that make up the Z^^^ uT^r^^ ^""^ 

, . / , . ^ - . example, it s common to run multiple copies of a Partitioned 

domain (e^S-.^nUUes, busmess processes, roles, etc.). Thus ^^^^^ Component across multiple Servers to handle a 

they provide the apphcation with conceptual mtegnty. That i5 greater transaction volume 

IS, the logical Business Components serve as the dirert Unk Deployment 3612, the Partitioned Business Compo- 

between the real-world busmess domain and the physical nents are packaged and deployed as part of the application 

application. An important goal is to build an application that into the production environment. The application parameters 

is closely aligned with the business domain. Later in the and the manner in which the Partitioned Business Compo- 

process. Partitioned Business Components and Engineering 20 nents are distributed are tweaked based on how well the 

Components provide a means for implementing, packaging, apphcation performs. 

and deployiiig the application. They also open the door to Well designed Business Components are anthropomor- 

improved integration, interoperability, and scalability. phic. That is, they take on characteristics and abilities as if 

FIG. 36 shows a relationship between business compo- were alive. This means that Business Components 

nents 3600 and partitioned business components 3602. Busi- 25 should reflect direcdy the characteristics and abilities (i.e., 

ness Components are an integral part of the previously information and behavior) of the business concepts they 

discussed Framework Designs. Business Cbmponents rep- represent. Therefore, only by examining the various types of 

resent real-world concepts in the business domain. They business concepts will one discover an acceptable way to 

encapsulate everything about those concepts including "^^^^^ Busmess Components. 

name, purpose, knowledge, behavior, and all other intelli- 30 ^^"^^ concepts come m a v^de variety. For example, 

gence a product represents somethmg of value that is up for sale. 

In the Business Architecture stage 3604, a project team 1*^^ ^^^f represents the work that needs to be 

* * «o ™^mi«,iiui^ auig^^ done to determme if a customer's credit is good. The former 

begms to define the apphcaUon architecture for an organi- ^ entity-the product^hile the latter 

zation s busmess capabihUes usmg Busmess Components. centered around a proces^^it check. 

Business Components model real-world concepts in the 35 This hue of thinking leads to two types of Business 

business domain (e.g., customers, products, orders. Components: entity-centric and process-centric, 

mventory, pricing, credit check, billing, and fi^ud analysis). Unfortunately, what commonly results from this paradigm is 

This is not the same as data modeling because Business an argument over whether or not a particular Business 

Components encapsulate both information and behavior. At Component is entity-centric or process-centric. In reality, 

this point in the process, an inventory of Business Compo- 40 Business Components are always a blend of both informa- 

nents is suf&cient, along with a definition, list of entities, and tion and behavior, although one or the other tends to carry 

list of responsibilities for each Business Component. more influence. An appropriate mental model is a spectrum 

In Capability Analysis 3606and the first part of Capability of Business Components. 

Release Design 3608, the project team designs Business Business Components on the entity-centric side of the 

Conoporients in more detail, making sure they satisfy the 45 spectrum tend to represent significant entities in the business 

application requirements. The team builds upon its previous domain. Not only do they encapsulate information, but also 

work by providing a formal definition for each Business the behaviors and rules that are associated with those 

Component, including the services being offered. Another entities. Examples include: Customer, Product, Order, and 

name for these services is "Business Component Interfaces." Inventory. A Customer Business Component would encap- 

The team also models the interactions between Business 50 sulate everything an organization needs to know about its 

Components. customers, including customer information (e.g., name. 

Throughout the remainder of Capability Release Design address, and telephone number), how to add new customers, 

and into Capability Release Build and Test 3610, Business a customer's buying habits (although this might belong in a 

Components are transformed into Partitioned Business Customer Account component), and rules for determining if 

Components based on the reaUties of the technical environ- 55 a customer is preferred. 

ment. These constraints include distribution requirements. Business Components on the process-centric side of the 

legacy integration, performance constraints, existing spectrum tend to represent significant business processes or 

components, and more. Furthermore, to ensure the concep- some other kind of work that needs to be done. Not only do 

tual integrity of the Business Component model, a given they encapsulate behaviors and rules, but also the informa- 

Partitioned Business Component should descend from one 60 tion that is associated with those processes. Examples 

and only one Business Component. In other words, it should include: Pricing, Credit Check, Billing, and Fraud Analysis, 

never break the encapsulation aheady defined at the Busi- A Pricing Business Component would encapsulate every- 

ness Component level. Also at this time, the project team thing an organization needs to know about how to calculate 

designs the internal workings of each Partitioned Business the price of a product, including the product's base price 

Component. This could mean the Engineering Components 65 (although this might belong in a Product component), dis- 

that make up the Partitioned Business Component, the counts and rules for when they apply, and the calculation 

"wrapper" for a legacy or packaged system, and other code. itself. 
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One might argue that the Pricing component is more process-centric Business Component (e.g.. Billing). User 

entity-centric than process-centric. After all, it's centered Interface Components 3808, on the other hand, require 

around the concept of price, which is an entity. In reality, further explanation. 

though, it depends on the business requirements, but again. As mentioned above, a User Interface Component is the 

whether or not a given Business Component is entity-centric 5 implementation of a business process that is user controlled, 

or process-centric is not important yet. What is important is explicitly it is a set of functionally related windows 

how well the Business Component represents its corre- that supports the process(es) performed by one type of user, 

sponding real-world business concept. The fact that most Examples include: Customer Service Desktop, Shipping 

business concepts arc a blend of information and behavior I>esktop, and Caim Desktop. These are not to be confused 
means that most Business Components should also be a 10 "^^^ low-level user mlerface controls (e.g.. Active X 

blend of information and behavior. Otherwise applications controls), rather User Interface Component 

would be much like they are today with a distinct ^aration l^^"^^^^.^ user interface controls. The reason for the 

r^f Ha fa anH r^rr^r^^^ J J f dashed aTTOw m thc diagram above is a subtle one. It pomts 

A *K ^ f ^- 1. u * *u * • r u to the fact that earHer in the development process User 

Another way to think about the process-centnc side of the Components are generally noTmodeled as process- 
spectrum IS by askmg, "What role performs the process?" 15 centric Business Components. Instead, they typically origi- 

For example, it s the picker-packer who picks inventory and ^ate &om the workflow, dialog flow, and/or user interface 

packs it mto a shipment. This might lead to the Picker- designs. See FIG. 39, which iUustrates the flow of workflow, 

packer component. Another example is a Shopping Agent dialog flow, and/or user interface designs 3902, 3904, 3906 

component that knows someone's buying preferences, shops to a User Interface Component 3908. This makes complete 

for the best deals, and either reports back to the user or 20 sense given their direct tie to user controlled business 

makes the purchase. processes. 

A pattern emerges when one examines the way these FIG. 40 is a diagram of the Eagle ^^lication Model 

Business Components interact with each other. Process- which illustrates how the different types of Partitioned 

centric Business Components are "in control," while entity- Business Components might interact with each other. Busi- 

centric Business Components do what they're told. To be 25 ness Entity Components 4002 and Business Process Com- 

more explicit, a process-centric Business Component con- ponents 4004 typically reside on a server, while User Inter- 

trols the flow of a business process by requesting services in face Components 4006 typicaUy reside on a client, 

a specific sequence according to specific business rules (i.e., FIG. 41 iUustrates what makes up a Partitioned Business 

conditional statements). The services being requested are Component 4100. As long as a component does what it's 

generaUy offered by entity-centric Business Components, 30 siqjpose to do, it doesn't matter what kind of code is used to 

but not always. Sometimes process-centric Business Com- build the component's internal workings. It could be any- 

ponents trigger other process-centric Business Components. thing from COBOL to Java. This is a key benefit of 

FIG. 37 shows how a Billing Business Component 3700 encapsulation. Classifying this code is a different matter, 

may create an invoice. The control logic 3702 (i.e., the Some code 4102 is specific to the Partitioned Business 

sequence of steps and business rules) associated with the 35 Component. Other code is more widely reusable, both 

billing process is encapsulated within the Billing component functionally and technicafly; this is where one finds Engi- 

itseff. The BiUing component requests services from several neering Cbmponents 4104. Another possibility is to "wrap" 

entity-centric Business Components, but it also triggers existing code 4106 from legacy and packaged systems. 

Fraud Analysis 3704, a process-centric Business Finally, it's important to note that patterns and fireworks 

Component, if a specific business rule is satisfied. Note also 40 are frequently used as starting points for designing and 

that "Step 6" is performed within the Billing component building this code. 

itseff. Perhaps this is where the invoice is created, reflecting Engineering Components are physical building blocks 
the design team's decision to encapsulate the invoice within used in the assembly of Partitioned Business Components, 
the Billing component. This is one valid approach. Another They are independent pieces of software that provide func- 
is to model a separate entity-centric Invoice component that 45 tionality that is generally useful across a range of 
encapsulates the concept of invoice. This would effectively applications, and they are usually packaged as black box 
decouple the invoice from the billing process which might capabilities with well-defined interfaces. Engineering Com- 
be a good thing depending on the requirements. ponents can be bought or built, and they come in a wide 

It would be logical to conclude that the two types of variety. Examples include: a workflow engine, a JavaBean 

Business Components translate to two types of Partitioned so that encapsulates a reusable concept like address or mon- 

Business Components, but a small adjustment is required. etary value, a complex user interface control that allows 

Entity-centric Business Components translate directly to users to edit a list of order lines, a group of objects 

Business Entity Components, but a closer look at the ways responsible for persistence, a JavaBean that sorts a coUec- 

in which a business process can be implemented in an tion of objects^ and a list box coded as an ActiveX control. 

appUcation reveals two possibilities for process-centric 55 A pattern is "an idea that has been useful in one practical 

Business Components. A business process can be: 1) context and will probably be useful in others." Think of them 

automated, like a billing process, or 2) controlled by a user, as blueprints, or designs for proven solutions to known 

like an order entry process. The former results in a Business problems. Having found the right pattern for a given 

Process Component, while the latter results in a User Inter- problem, a developer must then apply it Examples of 

face Component. 60 patterns include: an analysis pattern for hierarchical rela- 

FIG. 38 illustrates the relationship between the spectrum tionships between organizations and/or people, a design 

of Business Components 3800 and the types of Partitioned pattern for maintaining an audit trail, a design pattern for 

Business Components 3802. Business Entity Components applying different levels of security to different user types, 

3804 and Business Process Components 3806 are straight- and a design pattern for composite relationships between 

forward. The former is the physical implementation of an 65 objects. 

entity-centric Business Component (e.g., Customer), while A framework is a template for the implementation of a 

the latter is the physical implementation of an automated particular function (similar to a shell program). It usually 
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embodies a known pattern (or group of patterns) in a specific 
technical environment. Frameworks are available from a 
number of third-party vendors, and they are also developed 
on projects. Developers are typically expected to customize 
and extend frameworks to meet their specific requirements, 
but this involves a tradeoff. Customizing and extending a 
framework may optimize its use, but the resulting frame- 
work tends to be less abstract, and therefore less reusable in 
other contexts. Examples of frameworks include: a frame- 
work for displaying an object and its properties in Smalltalk, 
a Java-specific frameworic for persisting data, and a mes- 
saging and publish/subscribe framework for DCOM. 

FIG. 42 Ulustrates the role of patterns and frameworks. 
More specifically, it introduces the Eagle Architecture 
Specification 4200 and the Component Solutions Handbook 
4202, both of whidi are groups of patterns. Eagle also offers 
technology-specific starter kits 4204, which include frame- 
works for various environments. 

The pace of change in today's business world is increas- 
ing faster than ever before. Meanwhile, advances in infor- 
mation technology have enabled businesses to better under- 
stand their customers, provide greater value, and create new 
markets. However, as technology becomes more complex, 
applications have become more di£5cult and time- 
consuming to build and maintain. Looking forward, appli- 
cations must be dramatically more responsive to change. 
They must be more: 



In theory ... In practice . . . 

Flexible Making it poss&le to Making it possible to acoom- 

quickly satisfy new busi- modate a new product line 
ncss requirements by solely by iqidating the Product 

replacing or modifying conq>onenL 
certain components with 
minimal impart tO Others. 

Adaptable Making it easy to deliver an Making it easy to provide in- 
application to a variety of home access to customer 
user types through a variety account information by 
of deUveiy channels with developing only a new user 
minimal intact to the core interfoce while reusing 
application. exLstuig coKq»ttent8. 

Maintainable Making it easy to i^xlate an Making it easy to add a new 
application by reducing the customer attribute by isolating 
area of impact for most the change to one coitqx>n- 
changes. ent - the Customer compon- 

ent. 

Reusable Making it possible to Making it possible to as- 

qoickly assemble unique semble an application at a 
and dynamic solutions from fraction of the cost because 
existing components. eight of the twelve compo- 

nents that are needed already 
exisL 

Integration Making it possible to reuse Making it possible to absorb 

Ready the functionality within newly acqiiired divisions by 

existing systems by wrap- "wrapping" their systems and 
ping them as components "plugging" them into the 
within new applications. enterprise infrastructure. 

Interoperable Making it possible to Making it possible to integrate 

request services across two applications built on 
platforms. different platforms. 

Scalable Making is easy to distribute Making it easy to accom- 

and reconfigure compo- modate the holiday crunch by 
nents to satisfy various running multq)le copies of tbc 
transaction volumes. Order component across 

multq)Ie servers. 



Components will help an IT organization achieve these 
quality attributes. Through encapsulation they make it pos- 
sible to develop applications that are more responsive to 
change. One can make this claim with confidence because a 
component that is well encapsulated (i.e., an independent, 
black box component with predictable, well defined 



36,242 B2 

132 

interfaces) can be used in any situation, as long as it's used 
for its intended purpose. It knows bow to perform its 
services without regard to what's happening outside of its 
boundaries (e.g., the actions that precede or follow it). 

5 Another key to embracing change is the predictability and 
conceptual integrity of the parts that make up an appficadon. 
Fred Brooks, author of The Mythical Man-Month^ writes, 
. . conceptual integrity is the most important consideration in 
system design." Therefore, components must be conceptu- 
ally whole, and they must perform functions that are aligned 
with their purpose and within their ^here of knowledge. If 
they accurately reflect the real world, they are much easier 
to develop and maintain. If the real world changes, so must 
the corresponding component. 

Given a design with these characteristics, the opportunity 

1^ for reuse is significantly enhanced, and the time it takes to 
upgrade the system is dramatically reduced. The Gartner 
Group agrees that component-based development will be a 
dominant method of application development in the years to 
come. They say that "by 2001, at least 60 percent of all new 

20 applications development will be based on assemblies of 
componentware, increasing speed to market and the ability 
to cope with change (0.7 probability)." 

Business Components and Partitioned Business Compo- 
nents represent a major improvement in design capability — 

25 some might argue the first major change in design thinking 
since structured design. There are several reasons for this 
breakthrough: 

Business Components model entities and processes at the 
enterprise level, and they evolve into Partitioned Business 

30 Components that are integrated into applications that operate 
over a network. Consequendy, they serve as an excellent first 
step in the development of scalable, distributed enterprise 
applications that map closely to the business enterprise itself 
(i.e., the way it operates and the information that defines it). 

35 Business Components model the business, and thus they 
enable applications to more completely satisfy the business 
needs. They also provide a business-oriented view of the 
domain and consequently a good way to scope the solution 
space. This results in a good context for making process and 

40 application decisions. Finally, Business Components pro- 
vide a common vocabulary for the project team. TTiey 
educate the team in what's important to the business. 

When modeled correctly, entity-centric Business Compo- 
nents represent the most stable elements of the business, 

45 while process-centric Business Components represent the 
most volatile. Encapsulating and separating these elements 
contributes to the application's overall maintainability. 

To manage the complexity of a large problem, it must be 
divided into smaller, coherent parts. Partitioned Business 

50 Components provide an excellent way to divide and conquer 
in a way that ties the application to the business domain. 
They provide the ability to "padcage software capabilities 
into more manageable (and useful) chunks." By contrast, 
traditional modules are too cumbersome to be reusable in 

55 multiple contexts. On the other end of the spectrum, objects 
are too small to effectively divide and conquer; there are 
simply too many of them. 

Partitioned Business Components provide a greater 
emphasis on application layering — a well known, but often 

60 neglected concept in application development. 

Partitioned Business Components are application building 
blocks. As an application modeling tool, they depict how 
various elements of an application fit together. As an appli- 
cation building tool, they provide a means for systems 

65 delivery. 

Proven processes, patterns, and frameworks offer a higher 
level of reuse. This is one of the key advantages because it 
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means greater agility. These mechanisms make it possible building applications. Engagement experience has shown 

for hundreds of developers to do things consistently and to that it takes a couple of months to feel comfortable with this 

benefit from previously captured, reusable knowledge capi- paradigm — and longer for those pursuing deeper technical 

tal. skills. But this challenge is certainly not impossible to 

Business Components model the business. It sounds 5 overcome. A combination of training and mentoring has 

straightforward, but even with experience it's a challenge to proven to be the best way to teach these concepts, and the 

identify the right components and to (tesign them for flex- rigorous approach that results from this education is 

ibility and reuse. Flexibility and reuse are certainly more the journey. 

achievable with Business Components, but they are not The following tips and techniques provide an introduction 

inherent to Business Components. To accomplish these lo ^ ^"'^ ^"^^ surrounding the design of Business 

goals, as the previous examples suggest, one must under- °iS]?°f^"*u • i_ r - ^ 

stand what's happening withk the eiferprise and across the j,. ^^^^ le"& Components? How 

industry. One must work with business experts who under- ^n,^ n • * • xl„ 

stand the factors that wiU influence the m and fiituie f^'^'^'^ °l f^^^ Components ,s a frequen 

I r.i. I. . . rw/r ^"^"^^ topic of discussion. A fairly common misconception is that 

evolution of ^e business domam This will unprove one's 15 Business Components are the same as appUcations, but in 

ability to anuapate the range of possible change (i.e., to feet, appUcations are assembled from Business Components 

anticipate the future). The Business Component Model will (or Partitioned Business Components to be more accurate), 

be more flexible and reusable if it is chaUenged by scenarios A typical appKcation might have ten to twenty Business 

that are likely to take place in the future. Components. On the other end of the spectrum. Business 

Reuse becomes a reality more quickly if one plans for it. 20 Components are larger than business objects. In fact, some 

And it endures if one manages it over time. However, both people refer to Business Components as large-grained busi- 

of these things arc difficult to do, especially for large projects ness objects. 

and large enterprises. First of all, it's easy for communica- So what is the right size for a Business Component? 

tion across one or more projects to break down. It's also Business Components should encapsulate concepts that 

common for individual projects to pay more attention to 25 are significant to the business domain. Of course, this is 

their requirements and deadlines than to project-wide or subjective, and it certainly varies by business domain. In 

enterprise-wide reuse. After all, their most important objec- fact, business domain experts, with help from component 

tive is to deliver value to their customers. Reuse must be modelers, arc in the best position to make this judgment, 

engrained into the culture. This could mean teams respon- Bigger Business Components hide more complexity, 

sible for project-wide and enterprise-wide reuse, but no 30 which in general is a good thing. However, too much 

matter how it's done, rcuse must be one of the most complexity in a component can lead to many of the is 

important technology objectives. problems that preceded component-based development For 

Too much focus on low-level (i.e., code) reuse can be a example, embedding too much policy information can lead 

trap. To draw an analogy, take a look at the recent history of to a Business Component that is more difficult to maintain 

the auto industry. Some auto makers were focused on 35 and customize. Another advantage is the fact that the cou- 

inter-cbangeable parts and low-level standardization. For pling between bigger components tends to be weaker. On the 

example, they decided to use the same body style for all of other hand, bigger components are generally less cohesive 

their cars. Unfortunately, when the industry began to move and consequently less flexible. For example, assume that the 

away from the boxy body style, they were not weU prepared, concepts of warehouse and inventory have been combined 

nor were they agile enough to react in a timely fashion. They 40 into one Business Component. This could be problematic if 

had invested too much in low-level standardization. a future application needs warehouse information, but not 

Conversely, other auto makers were focused on quality inventory information. 

processes and frameworks (i.e., high-level reuse). As a SmaUer Business Component tends to be more flexible, 
result, they were able to respond more quickly to the It's also easier to reuse them in future applications, 
changing requirements. Engagement experience has shown 45 Unfortunately, smaUer components typically result in a 
that the same thing can happen with components and objects higher degree of coupling. One will find significantly more 
(e.g., too much emphasis on low-level inheritance). That's interactions between smaller components. This could also 
why it's important to focus appropriately on the high-level lead to perfoimance problems. If two or three small corn- 
reuse enabled by processes, patterns, and frameworks. ponents send each other a lot of messages, it might make 
Although Business Components and Partitioned Business 50 sense to combine them into one. SmaUer components may 
Components represent a significant breakthrough in design also be more difficult to manage, simply because more of 
capability, the architectural frameworks to support this them exist. 

breakthrough are still maturing. Standards come to mind It's important to strike a balance, and keep in mind that 

first: Wll it be COM, JavaBeans, or CORBA? It's stfll not flie ideal size depends on the domain. If there's a question 

clear. Likewise with languages: Wih it be WisaaX Basic, 55 in one's mind, it makes sense to lean toward smaller 

Java? Tools and repositories offer another challenge. Clear components. It's easier to combine them than to break them 

winners have yet to emerge, and newcomers are constantly up. 

popping up with promising products. Finally, the legal and What's the best way to identify Business Components? 

commercial market for buying and selling components is not Ehiring the Business Architecture stage, the project team 

maturc. The market for high-level common business objects 60 defines its business capabilities. At this point in the process, 

is just emerging, while the market for low-level components one can begin to search the business domain for Business 

is stiU chaotic. Components. Then again later, during Capability Release 

One of the most important challenges is teaching a new Design, when the project team documents scenarios and 

application development style. Although components and workflows, one can perform a second iteration through the 

objects have been aroxmd for a while, they are new to most 65 identification process. 

people. Furthermore, component-based development The following steps describe one technique for identify- 

requires a change in the way one thinks about designing and ing Business Components. FIG. 43 illustrates this Business 
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Component Identifying Methodology 4300 including both From a logical perspective, components and objects arc 

Planning and Delivering stages 4302, 4304: the same. They both model concepts from a particular 

1. Start with entity-centric Business Components. For domain, and they both encapsulate information and behav- 
example, the customer is a significant entity in most ior. On this level, good component models and good object 
business domains, therefore a Customer component 5 models share the same characteristics: high cohesion, low 
may be included. A Customer Business Component coupling, reusability, well defined services, and more. One 
would encapsulate everything an organization needs to might aigue that granularity is a key difference. After all, for 
know about its customers, including customer infor- an object-oriented design, components arc made up of 
mation (e.g., name, address, and telephone number), objects. This may be true, but in rcahty both of them come 
how to add new customers, a customer's buying habits 10 in all sizes, thus making this difference rather insignificant, 
(although this might belong in a Customer Account From a physical perspective, components and objects are 
component), and rules for determining if a customer is similar, but different. The key difference relates to the 
preferred. Entities themselves can be physical or con- different ways in which they are implemented. As long as a 
ceptual. For example, customers and products are component's interfaces comply with an accepted standard 
physical— you can touch them. Orders, on the other 15 hke COM, JavaBeans, or CORBA, its internal workings can 
hand, are conceptual. An order represents a specific be implemented using any technology (e.g., Java, Visual 
customer's demand for a product. You cannot touch Basic, Smalltalk, C, or even COBOL). The internal work- 
that demand. ings of an object, on the other hand, can only be imple- 

2. Look for process-centric Business Components next. mented using object technology. For the same reason (i.e.. 
Generally speaking, a process-centric Business Com- 20 staiKlard interfaces), it is possible to request a component's 
ponent controls the flow of a business process. For services from any platform. That's not true of objects, unless 
example, in the utility industry, a Billing component they are wrapped with interfaces that comply with the 
would process customer, product, pricing, and usage accepted standards, which would make them distributed 
information into a bill. Sometimes one will find an objects (i.e., components) instead. 

entity associated with the process — in this case, a bill 25 Robert Orfali, Dan Harkey, and Jeri Edwards also wrote 

or invoice — but another option is to model this entity as the book The Essential Distributed Objects Survival Guide 

a separate, entity-centric Business Component, thus (1996). Chapter 2, "From Distributed Objects to Smart 

decoupling it from the process. Component," is an excellent source of information about 

What's the best way to identify the responsibilities of a objects, components, and the differences between them, 
business component? 30 They say the following about physical components: 

Review the business capabilities, business processes, A component is an object that's not bound to a particular 
business practices, scenarios, workflows, and other require- program, computer language, or implementation . . . They 
ments. Look for behaviors that will be supported by the are the optimal building blocks for creating the next gen- 
application. In other words, what are the business functions eration of distributed systems . . . Components are standa- 
that will be performed by the system? Assign them as 35 lone objects that can plug- and -play across networks, 
responsibilities to the most appropriate component If com- applications, languages, tools, and operating systems. Dis- 
ponents were people and computers didn't exist, one might tributed objects are, by definition, components . . . Unlike 
ask, "Who is responsible for this task?" In fact, sometimes traditional objects, components can interoperate across 
it's helpful to assign component owners who speak up when languages, tools, operating systems, and networks. But 
they encounter a responsibility that should belong to their 40 components are also object-like in the sense that they 
components — ^Hey, I should be responsible for that!" support encapsulation, inheritance, and polymorphism. 

This section addresses several frequently asked questions What is a component model? 

that more broadly apply to the physical implementation of This is a common point of confusion. From a logical 

component- and object-based solutions. The answers are per^ctive, the term "component model" is fi^uently iised 

intended to increase the awareness of the reader. Most of 45 to refer to a Business Component Model in the same way 

them only scratch the surface of issues that are somewhat that "object model" is used to refer to a business object 

controversial within the component and object community. model. 

What is the role of components in net-centric computing? From a physical perspective, a component model (or a 

Physical components play a critical role in net-centric component object model) defines a set of conventions that 

computing because they can be distributed, as encapsulated 50 provides a standard way to develop and use physical 

units of executable software, throughout a heterogeneous components, including how to define properties, events, 

envirorunent such as the Internet. They have the ability to behaviors, etc. It also includes the standard structure of a 

make the Web more than a toy for retrieving and download- component's interfaces, the mechanism by which a compo- 

ing information. Robert Orfali, Dan Harkey, and Jeri nent interacts with other components, patterns for asking a 

Edwards, well-known experts in the field of component- and 55 component about its features, a means for browsing active 

object-based development, wrote the following about dis- components, and more. Some of the existing component 

tributed objects (same as "distributed components" for the models are COM, JavaBeans, and CORBA. 

purpose of this discussion): Example: A Grocery Store 

The next-generation Web — ^in its Internet, intranet, and A grocery store chain is creating an enterprise-wide 

extranet incarnations — must be able to deal with the com- 60 Business Component model. Currently the individual stores 

plex requirements of multi-step business-to-business and do not record specific customer information, 

consumer-to-business transactions. To do this, the Web must Consequently, a model based on today's requirements 

evolve into a full-blown client/server medium that can run would not retain customer information, 

your Hne-of-business applications (i.e., a delivery vehicle However, they are looking into preferred customer cards, 

for business transaction processing) ... To move to the next 65 Furthermore, while analyzing the industry, the project team 

step, the Web needs distributed objects. reads about a competitor with a pharmacy and video rental 

What's the difference between components and objects? service. In both cases, customer information becomes criti- 
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cal. So Ihe project team creates scenarios describing how Another unreasonable expectation is the belief that com- 

they would use customer information to support these ponents may provide immediate software reuse. Experience 

requirements. Hiey create one Business Component Model has shown that reuse is not automatically attained; it is 

that supports both today's and tomorrow's view of the necessary to establish a disciplined approach to reuse and 

customer. 5 create a development culture that embraces reuse. 

In the near future, when the chain adopts preferred ^ client's view of component technology may vary 

customer cards, and in the more distant future, if they decide depending on their previous experiences. Client's with no 

to add a pharmacy or video rental service, the Business component or object experiences may have the most unre- 

Component design for their current application will provide expectations for what the technology can delivery. In 

a soUd foundation for the future requirement of tracking lo ^^^t^^^' clients Oiat have attempted objectnoriented appU- 

customer information. If they weren't using Business cations and faded may understand 

Components, they would not have a model that maps to their ^^nfc 1"^^^ Z ^'''""T.t '° k?: 

\ chents may require additional evidence of the viabibty of a 

busmess domau, and mtroducmg new requuements would eomponent approach. For these clients, a com,^nent 

require more abrupt chanees. u tL i- • ■ . 

, , . .. , approach can be very appeahng since a component-based 

Example: Inventory Management is j^hitecture can combine both Lditional and object tech- 

A telecommunications «,mpany m the paging business oologies. And lastly, there is the thin! category of cUents that 

sells and leases pagers and services. One part of the com- h^^^ ^^^^ ^^^^ „j success with object tech- 

pany IS mstaUing an mventory management system for „„, ^ component technology as the natural 

tracking pagers, whfle another part of the company is ti^mg ^^^^^^^^ ^^^^ ^ ^ ^ „^ ^^^^^ 

to deteimme how to track the frequencies that are owned and 20 (,„ object technology alone 

leased by the company. What does this company mean by Cbmponent-based Development's Focus on the Long-Term 

mventory? Does It simply mean knowing what Items are m is Usually a Good Tradeoff 

a warehouse*^ 

^ ■ .u- 1 u... .1 I. . .u . r Component-based development is also inherently biased 

• thf «>'np'»"y thmks abstracUy about the concept of Awards the long-term. For example, the development pio- 

myenloiy. they d^er that it s aU about managing any- 25 eess strives for a higher degree of quality and ,e\^, inior- 

thing of value When they look at what they have in porating iteration between fcsign and code to support reflne- 

mventory, they discover that it is countable leservable, and striving for this higher design quality may almost 

has a cos^ associated with it. Inventory does not lequne ^ ^y definition, cost more up front. Despite these 

specific knowledge of the use of an item m inventory; that component-based development's focus on the 

toowledge can be pu mto anotter component, s^^^ 30 j ^rm makes economic sense. Experience has shown 

If mventory does not need to know the specifics about its 60-80% of development costs are in maintenance. 

use^toenitcouldapply,teabjbtytocount,resetve^dva^^ K^^t , p^^^ Champion or Sponsor with a Long-term 

anything it is assoaated with. Inventory could be used to Pocus e 

manage a variety of thinp: conference rooms^ fixed assets, ensure that short-term concerns do not outweigh the 

work in process, fimshed goods, and leased frequencies. 35 ^^^^ (^^fl^^ management should mainlain a 

So one can ^art out bmldmg an mventory management „f jhe benefits and risks of components. ITnis, 

apphcauon and then budd the ready-to-ieuse Inventory ^ ^ j„„ „^ ^ ^^^^ 

component which, without modificabon. can support many loBg.fcnn view is a key to success, 

other use^ In ths way one <an unload the concept of jj^^g^ ^ust Support Adoption of Component 

mventory so that it can be reused outside the context it was 40 Technology 

initiaUyplamed for. Establish Qear Goals for a Cftmponent-based Project 

Thissertion highhghte key messages for project manage- Component technologists sometimes promote component 

ment.lTieManagementLessonsdisa.«thesepomtsfurther. development for its own sake, without regard for thTbusi- 

ve3 Expectations^mponent Technology is Not a Sil- ^^^8 benefits. However, rarely may mimagement justify 

^*S> * . - . 1. L -.- - . . something they do not understand. Component technology 

Ctomponents promise to entoice the abdity to quiddy introduces a daunting array of new terminology, 

budd robust systems through the use of reusable pre-budt Furthermore, if a pilot component project is launched v^th 

software components. Properly leveraged, components can unclear goals or mission, the significant short-tenn costs and 

provide the foundation Upon which one meet and exceed the ^Z. • % ui j • *l . . 

J J r 1 i_ 1 ^ , uis^» vA^u uiw challenges may inevitably undermine the oomimtment to 

demands of a global marketplace which increasingly uses 50 components 

technology as a primary competitive advantage, like object ^hus, component technology must be justified in business 

technology before components are often portrayed as the ^^^^er than technology terms. In many cases, a traditional 

magic sJver bullet o slay the lUs of software technology. cUent/server solution can deUver the benefits. Hiis proves 

Yet the silver bullet mentality inevitably leads to unrea- short-lived, simple, or moderately com- 

sonable expectations. Intense media attenUon fuels these 55 plcx applications. On the other hand, component teclmology 

expectations. For example, components are often compared applications with characteristics such as: 

to Lego blocks that are simply plugged together to form ^ ^ maintenance life 

complex systems. Experience has shown, however, that , . . 

component technology is not that simple and that payoflfe are comP^ex processmg or significant asynchronous logic 

primarily in the long term. There are several factors impede 60 con^P^ex data relationships 

short-term payofEs. very dynamic business requirements 

Most important, demand exceeds supply for professionals multiple access channels 

with component and object-oriented skills. Thus, many - legacy evolution or replacement 

initial projects incur start-up costs related to recruiting, functionality common across multiple applications 

training, and learning curve. Furthermore, after receiving 65 Firm Clients Have Achieved Business Benefits 

investment in training, individuals find themselves in The number of engagements that have employed compo- 

denoand, becoming higher risk to leave the organization. nent and object technologies has continued to grow over the 
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last few years. These engagements have shown that object 
and component-based approaches can lead to significant 
business benefits. 
Reduces Maintenance Costs 

Properly designed component-based systems shoidd 
reduce maintenance costs. Encapsulating implementation 
details and data make a system more resilient to changes in 
the business or underlying technology. Furthermore, design 
decisions must rigorously consider what is likely to change. 
Susceptible points should be bidden behind an abstract, 
public interface that decouples their potential changes from 
impacting other components. 
Component Reuse Reduces Development Time 

Components are more easily reused because they provide 
weU-defined interfaces and can often be used through visual 
development tools. This make it more straightforward to 
develop components for one project and share them across 
other projects. Furthermore, components can be designed so 
that their properties can be tailored to meet varying require- 
ments. Once a reusable base of components has been 
establii^ed, the development time for subsequent projects 
can be reduced. 

In one utility company they saw significant gains in the 
reuse of components across initiatives. Rather than copying 
and tailoring source code for new initiatives they were able 
to assemble applications from already created components. 

Another engagement estimated that new system develop- 
ment was reduced 25% once the first application was 
released and a core set of components was established. Even 
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development, and increased effort for component and 
assembly testing. However, once core, reusable objects in 
the domain model and application framework stabilized, 
system testing the functionality and performance was much 
easier. For example, since less code and data knowledge was 
replicated throughout the system, global changes could often 
be made by making a change in one place. 
Component Technology May Help Improve Communica- 
tions with Users 

The close tie that component and object modeling enables 
between the software solution and business process may 
help software analysts and users or business analysts to 
better understand each other, reducing errors in communi- 
cations. This represents a significant opportunity, because 
misunderstanding user requirements has been proven to be 
the most costly type of mistake in systems development. A 
component model further improves the understandkg of the 
software design by providing a larger-grained model that is 
easier to digest. 

Lastly, communication with users is often improved by 
using scenarios which convey requirements through familiar 
business situations. 
Multiple Access Channels 

Component architectures are inherently service-oriented. 
Components provide their services through interfaces whidi 
consist of operations. Because components are independent 
pieces of software they can be reused by any number of 
applications. Thus, component-based architectures are well 
suited to envirormients that need to provide multiple appli- 



though the engagement ultimately realized the benefits of 30 cation "personalities" or access channels. New personalities 



reuse, the client still had the expectation that reusable 
components would save time and money for the first project. 
To manage this expectation, the project team needed to 
re-emphasize that component-based development requires 
an initial investment. 

Leverage Existing Technology Investments 

Many clients have existing technology assets that would 
require significant investments to replace. Components can 
enable these legacy systems to be wrapped with component 
interfaces so that new applications can easily interact with 
them. Later, these legacy applications could be replaced 
without changes to the new applications. 
Shields Complexity and Supports Re-engineered Processes 
Objects Raise the Level of Abstraction in the Software 
Solution 

Object development enables closer integration between 
developing applications and reengineering business pro- 
cesses. The first object-oriented language, Simula, was 
invented to enable simulation. It and other object develop- 
ment environments provide capabilities that raise the level 
of abstraction of the software. That is, object-oriented lan- 
guages and design techniques enable writing software in 
terms closer to the real-world business rather than the 
computer. 

Enables Improved Usability 

Object-oriented technology can support improved usabil- 
ity in two ways. First, objects messaging each other lends 
itself to simplified programming of advanced, direct 
manipulation or multi-media interfaces. Second, an object 
metaphor for designing the user interface may be a more 
desirable interaction style for some types of users such as 
knowledge workers needing flexible navigation. 
Reduces System Test Complexity and Cost 

In a few different instances, the object-oriented develop- 
ment approach has significantly reduced system test com- 
plexity. In all these cases the projects fell behind schedule 
due to learning curve, the complexity of custom architecture 
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can be provided by creating a new user interface layer that 
reuses the existing business components. 
Managing Risk is Key 

Component technology is still high risk, because it may 
often: 

have a pervasive impact on the overall development 
approach 

require inunature technology or tools 
implicitly involve complex functional requirements 
Component-Based Envelopment is not only New Tech- 
nology; it is a New Approach to Software Engineering 

Comporient-based development should not be understood 
as just a technology decision; rather, it is a new approach for 
software engineering. Thus, it affects almost all aspects of 
development including methodology, tools, organization, 
and architecture approaches. This broad impact creates 
multiple learning curves, complicating the migration of an 
organization. Finding available skills is also difficult, 
because demand currently outweighs supply. 

Component-based systems may also require immature 
technology or tools. Many of the core development tools 
such as the programming language and environments for 
C++, ^%ual Basic, Java and Smalltalk are actually very 
robust. However, some of the ancillary tools sudi as ib& 
CASE tools and web development tools or technology 
architecture components such as messaging middleware 
may not be as mature. Thus, the team may face a choice of 
managing some risk exposure with a tool or library that 
simplifies development, or avoiding this tool risk but facing 
a more complex development challenge. 

Another, more subtle source of risk is the inherent func- 
tional complexity of applications often chosen for 
component-based projects. Component technology's tech- 
nical characteristics enable dynamic, functionally complex 
systems. For example, business reengineering can capitalize 
on the inherent flexibility of component-based systems. 
However, reengineering creates more dynamic functional 



us 6,636^42 B2 
141 142 

requirements, thereby increasing risk. Not to mention that smaller-grained business reuse and increased coupling 

business reengineering is itself a risky venture. between presentation and data. This may increase mainte- 

Thus, proactive risk management is an essential practice nance costs and miss opportunities to flexibly model com- 

in development. Traditional risk management techniques plex business processes, as can be done with a component 

apply to component-based projects. For example, a "top ten" 5 model. On the other hand, producing a reusable component 

risk list can help focus management attention. This risk model requires a higher level of abstraction and is therefore 

focus must then influence the development tasks carried out a more difEcidt approach, 

by the team early in the project to ensure risks are addressed Component Systems are Based on Standards 

in a timely fashion. Component-based systems are also usuaUy distinguished 

Architecture is Essential to Delivering the Benefits lo by their use of one or more of the leading component 

Component Technology Enables i^lication Frameworks standards, i.e. CORBA, DCOM, or JavaBeans. These stan- 

Component-based systems extend the notion of architec- dards define the mechanisms that business components may 

ture beyond that in a traditional system. Much of the power use to communicate with each other. However, a system 

of component-based systems is the ability to leverage appli- does not necessarily have to use one of these technologies to 

cation frameworks. Frameworks are somewhat analogous to is be considered component-based. The most important criteria 

program shells found in a traditional environment such as is that the application is made up of reusable, service- 

the INSTALL/1 online system with components like MES oriented building blocks that encapsulate their functionality, 

and CCP. However, this is only an approximate analogy. An Component-based Systems Can Incorporate a Variety of 

application framework goes beyond traditional application Technologies 

architectures to provide a greater degree of default behavior 20 Clients Can Select the Most Appropriate Mix of Technolo- 

and flow of control in a skeleton of the application. gies 

For example, traditional program sheUs rely heavily on Just as none of a user's client experience with objects has 

cut-and-paste techniques to achieve reuse. TTiis places a involved migration to a completely pure object solution, 

heavier burden on the developer and exposes the structure of components may involve a variety of technologies. This is 

the application. With an application framework, object- 25 even more true for component-based systems since they 

oriented capabilities minimize or eliminate the need for provide the ability to integrate different technologies 

cut-and-pastereuse.AweU-designed framework reduces the through well-defined interfaces. The ease of integration is 

burden on application developers by providing an architec- very appealing to clients since it allows them to maintain 

ture environment that effectively says, "Don't cafl us, we'U their existing technology investments, leverage their cxist- 

callyou." 30 ingskiUs, and select a mix of technologies that best fit their 

There are many frameworks within the Java programming tolerance for risk, 

environment. For example, Java Security, a very important More Diverse Skills May be Required 

topic in new netcentric architectures, provides a Java Secu- Because components can be implemented in a variety of 

rity Framework. This is a plug and play framework that programming languages on a number ofplatforms, it is often 

aUows developers the option of pluggi n g in a security 35 necessary to have competencies in a number of technolo- 

provider of their choice O^ES, RSA, etc) or developing a gies. For example, one client used \%ual Basic, Smafltalk, 

custom security solution that can be called by security C++, and COBOL for different layers of the system. The 

clients. To create a new security provider, the developer increasing number of technology combinations also 

must only implement the required interfaces for the frame- increases the complexity associated with development 

work and provide a weU-known name. Once these require- 40 activities such as testing, debugging, and configuration 

ments are met, the component can be plugged into the management. 

framework. Component Can Wrap Procedural i^lications 

Component-based Systems are EHstinguished by a Business Wrapping is a technique to integrate traditional system 

Component Model components. It applies to both the application and system 

The Presence of a Reusable Business Component Model is 45 levels. For example, a component can provide a public 

a Key Characterise interface, encapsulating a legacy appUcation. 

A component-based software architecture may have a Wrapping can be effectively applied to integrate a legacy 

domain component model shared by the application pro- biUing system with a large, d)ject-oriented customer care 

cesses. The component model contains the core business system. 

components that represent the business directly in software. 50 At the architecture level, wrappers often provide database 

These components perform behaviors upon request by interface objects to shield the application from the database 

windows, reports, or batch process control objects. vendor. 

The presence of a component model distinguishes Architecture Development Must Start Early 

component-based systems from procedural, client/server A Tension Exists Between Scenarios and Frameworks 

systems. In a procedural approach, there is no shared busi- 55 As with client/server, architecture work must start early, 

ness component model. This typically requires, for example, As noted above, this is particularly challenging because of 

programs to pass data to each other in a context record. Thus, the level of application reuse in a well-designed apphcation 

any changes to the data may affect many programs. The framework and domain component model. Because of this 

extent of business logic reuse is also usually less with the reuse, the framework must be heavily driven by application 

procedural approach. 60 requirements, or scenarios. Yet, the architecture team must 

The presence of a business component model also distin- stay one step ahead of application development teams to 

guishes a component-based architecture from that produced ensure that the architecture and component model are ready 

by componentware tools. Specifically, many traditional and in time to be reused. Thus, a difficult tension exists between 

even component-based tools provide data-aware controls scenarios and frameworks. 

that tie the user interface directly to the database. This is 65 The tension between scenarios and frameworks can be 

indeed a powerful technique to rapidly build simpler, less simplified to the extent that third-party or standard archi- 

strategjc applications. However, it suffers from a lack of lectures sudi as Eagle can be leveraged. In any case, the 
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following guidelines should be considered, particularly for Estimating and Planning Present New Management Chal- 

custom architectures: lenges 

The architecture should be defined and prototyped, if Projects Should Allow Time for Start-up Costs and Contin- 

necessary, early in the preliminary design gencies 
The architecture should be complete-at the very least, the 5 There is still not enough experience with component 
development architecture and overall framework, prior technology to support rigorous, detailed metrics. One rea- 
to developers actuaUy coding; the design must be in sonable checkpoint for estimating an initial project is to use 
place earlier when functional developers start detailed traditional techniques, and then add time to adjust for 
design; pnvate architecture a^ts may be deferred contingency and start-up costs such as training, learning 
Time must be planned for architecture support based upon lo curve, and architecture development. Early client engage- 
unforeseen scenarios, performance tuning, documenta- ments have demonstrated that an initial project may ahnost 
tion and developer mentoring always be more expensive due to these start-up costs. 
Developing a custom application framework should be Yet, care should be exercised in applying traditional 
estimated as a set of tasks in addition to much of the estimating metrics. For example, traditional metrics often 
traditional technology architecture development 15 use number of days per window or report. Cbmponent-based 
New Roles and Oiganizadon Strategies must be Introduced development can result in significantly different window 
Component Projects Require Modeling Skills counts for similar functionahty. 

Most traditional engagements divide roles into two basic In addition, the fixed versus variable nature of costs 

categories, functional and technical, or architecture. should be considered. Start-up costs are often not simply a 

Component-based development introduces a third dimen- 20 variable percentage of the project size, because roughly the 

sion by requiring an extensive modeling role. Early expe- same architecture components may be required independent 

rience has shown that the capability to draw abstractions in of size. Thus, anecdotal evidence suggests that the start-up 

modeling a business problem or application framework is a costs usually have a greater effect on a small project, 

unique skill set distinct from purely technical or fiinctional Development Requires a Mix of Waterfall and Iteration 

skills. 25 Systems development traditionally relies on a waterfall 

Managing the I>omain Component Model Reqiiires New model. This approach manages development in sequential 

Organization i^proaches phases of activity such as analysis, design, code, and test. 

In addition, the extensive reuse of a core business com- The waterfall provides control and discipline to 

ponent model requires an organization structure that man- development, particularly critical for large, mission-critical 

ages it as a shared resource. This creates a tension between 30 efforts. 

the needs to support consistent reuse of core components. On the other hand, iteration enables proving out design 

and the desire to solve a business problem finont-to-back. assumptions in code early in the process, and testing the 

Experience has shown this often requires some form of validity of code before proceeding on a wide scale. The 

matrix organization, combining vertical-based leadership information and learning gained from iteration are especially 

along the lines of business fimctions, and horizontal-based 35 important for component-based development, because it is 

leadersh^ along the lines of architecture layers. so new. As component-based architecture and methodolo- 

Leveraging Expert Mentors and Hme are Key to Scaling the gies mature, the need to iterate may be reduced 

Learmng Curve Significant Planning and Status Monitoring is Necessary to 

The Learning Curve is Greater, because it has Multiple Manage Iteration 

Dimensions 40 However, managing iteration on a large scale is difficult. 

Component-based development involves a longer learn- The team can easily slip into hacking, in which design is 

ing curve than comparable software technologies, because it simply skipped before coding. Or, a team may use iteration 

has multiple dimensions. Component technology skills as an excuse to not exercise due diligence in completing 

cover a wide range of competencies — from modeling and tasks. Thus, a merging of waterfall and iterative principles is 

design skills to detailed programming syntax. Yet, a user 45 beneficial. Yet, striking a compromise between waterfall and 

may have good success with people scaling the learning iteration is not easy. Thus, significant effort must be invested 

curve in a reasonable amount of time. for detailed workplarming and status monitoring. 

Programmers can expect to perform simple tasks in 2-4 Incremental Development May Help Manage Scope and 

weeks when an architecture is in place. More complete Risk 

implementation skills may require 8-24 weeks. Design 50 Incremental Development Partitions the System RoU-out 

skills also typically require the same amoimt of learning into Releases 

curve, 2-4 weeks for simple tasks and 8-24 weeks or Perhaps the most effective way to mitigate the risks of a 

slightly more for complex design problems. Usually pro- large project is to simply avoid being large. Incremental 

gramming should precede design experience, if possible. development addresses risk by reducing the necessary team 

Thus, leveraging experienced component and object tech- 55 size and scope. "Incremental" and "iterative" development 

nology skills is key to success. Even a few skilled compo- are often used interchangeably, but they are different 

nent developers can provide significant leverage to mentor approaches. 

and support an inexperienced development team. Experi- Incremental development partitions the system roll-out 
ence has shown that at least 20% of the development team into successive releases. For example, the initial release of 
should have component technology or process skills at the 60 a customer system might comprise order processing, fol- 
outset. This represents a minimal level for large engagement lowed by a subsequent release for biUing, and a third release 
teams with projects of one year or more duration. Smaller for collections processing. Thus, incremental development 
teams or shorter duration projects may typically require adds new functionality, while iterative development con- 
more. It is also extremely important to have a significant tinuously refines existing functionality, 
percentage of the team with client/server skills, to reduce 65 Incremental development avoids the complexity of a big 
additional learning curves such as GUI design or client/ bang integration. Furthermore, although an incremental 
server architectnre development. approach delivers less in each successive release, it can 
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deliver higher priority portions of the system much earlier On the other hand, excessive application tuning should 
than a traditional approach, thereby recognizing business not be done to the exclusion of following good design 
benefits in a Sorter time frame. principles, especially if the components are built using 
Despite these benefits, incremental development is not a object technology. Experience has shown that dramatic 
panacea. Many times a big bang conversion has proven 5 performance improvements can be made late in object- 
necessary, if the cost and risks of having parallel systems oriented development projects. Furthermore, following good 
and bridges, performing conversion, and rolling out training design principles actually better enables these tuning capa- 
arc high. These costs must balance those introduced by the bilities. 

delayed delivery of business benefits and the risks implied However, if more traditional approaches are used to 

by increasing scope and team size. The urgency of the lo implement the components, then it may be more appropriate 

business and the desire to manage development size may to tune performance throughout the development lifecycle. 

sometimes favor an incremental approadi. Third-party Components Have Increasing Importance 

Commercially Available Methodologies Have a Narrow Third party components can play an important role in 

Focus software development. Today's development tools make it 

Most component-based methodologies focus primarily on 15 easy to incorporate off-the-shelf components and customize 

analysis and design techniques. For example, less guidance them to a project's specific requirements. Thus far, off-the- 

is available for configuration management or testing. Yet, shelf components have primarily consisted of user interface 

both of these aspects are more complex with component- o*" architecture components. One project bought third party 

based development, because of the greater level of granu- components for the user interface, device drivers* bar- 

larity of the software decomposition. Because the method- 20 coding, and database drivers. This project foimd that it saved 

ologies are generic, they jdso typically do not address a significant amount of time, especially in areas that required 

detailed architecture or design steps. specialized programming skills. Unlike architecture 

Configuration Management and Testing are More Cbmplex components, it is not likely that third-party business com- 

As noted above, the increased granularity of a ponents may be available any time soon, 

component-based system and the variety of technologies 25 Staffing, Training and Skills I>evelopment 

associated with it complicate testing and configuration man- This chapter discusses management issues related to 

agement. A component-based system may often have more staffing, training, and skills development, 

than ten times as many components as a traditional system. Component-based Systems Require a Mix of Technical 

While component-based systems arc more granular than Skills 

purely object-oriented systems, configuration management 30 Object Skills are Conmion, but Not Required 

is not necessary less complex. While the use of components Components and objects are frequently considered to be 

allows objects to be packaged into more comprehensible equivalent tedmologies; however, they are not one in the 

interfaces, it also increases the number of elements that need same. While object-oriented systems may be developed 

to be managed. Typically, the following entities may be using object-oriented analysis, design, and programming, a 

tracked: 35 component-based system can be developed using a wide 

Methods variety of languages, including procedural ones. As a result, 

Q^^^ the required depth of skills for a component-based project 

„, y. . ^ V may depend on the blend of technologies used. For example. 

Packages (which are often aligned with components) one project may require skills in COBOL, C++, and 

Components ^ Smalltalk, while another may use V^ual Basic exclusively. 

Configurations Because many projects are building components with 

Applications objects, deep object-oriented skills may continue to be an 

Configuration management requires a compreheixsive essential ingredient in the success of a project 

approach of tools, procedures, and organization approaches. Competencies in Multiple Tedmologies May be Required 

Multiple levels of component ownership must be defined. 45 Since component technologies make it possible to inte- 

The higher level of reuse requires frequent roll-outs of different platforms, languages^ and other technologies, 

updated component versions. This also typically requires the il is often necessary to develop a broad portfolio of skills on 

workplan and other status monitoring techniques to track ^ project. It is important to develop an early understanding 

dependencies between components at a much lower level of of the different ^ills required and bow they can be devel- 

detail. 50 oped and leveraged across a project. 

In addition, completing a set of processing requires many Leveraging Experienced Component Practitioners is Key 

software components working together. Thus, testing Leveraging experienced component technology skills is 

involves integrating many more components. The complex- lo success. Even a few sldlled component developers 

ity is magnified, because the integration work often cuts can provide significant leverage to mentor and support an 

across different developers. The testing strategy must gen- 55 inexperienced development team. 

erally include more testing phases, each specifying a lower At least 20% of the implementation team should have 

level of detail. Furthermore, automated regression testing component skills 

has proven essential to address the complexity of integra- Small teams or short projects likely require more 
^OQ- Experience has shown that at least 20% of the develop- 
Address Performance Risks Early, but Defer y^lication 60 ment team should have object/component technology or 
Tuning process skills at the outset. These represent minimal levels 
Timing when to address performance has subtle com- for large engagement teams with projects of one year or 
plexities for a component-based system. Certainly, more duration. Smaller teams or shorter duration engage- 
component-based development involves new technologies ments need a higher ratio of experienced component devel- 
that introduce performance risks. Prototyping architecture 65 opers. Furthermore, custom building the architecture &om 
components should be initiated early to adequately address scratch may generally demand even more and deeper skills, 
the performance risks. unless the team has exceptionally talented individuals. 
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extensive client/server experience, and ample time to scale Experience with client/server development and a technical 

the learning curve. orientation 

It is important to note that component technology skills Willingness and flexibility to leam new terminology, tools, 

cover a wide range of competencies — from modeling and and techniques 
desigQ skills to detailed programming syntax. Rarely may 5 Strong communication and people s kills 

one individual have the necessary expertise in all these Sound understanding of the system's development lifecycle 

areas. Thus, experience has shown thai it is necessary to find and the risks at the various stages 

individuals that specialize in one of these areas to leverage Architecture Roles Require Diverse Skills 

across a large team. The key is obtaining the right balance Complicating the search for architecture skills is the need 

of technology and methodology skills. to find developers who also possess the necessary commu- 

One Engagement Used a 1:1:1 Rule to Leverage Expertise nications and teamwork skills. The architecture team must 

One large engagement found the most effective leverag- be capable of both delivering an application framework, and 

ing ratio was 1:1:1, comprising an experienced object giving people appropriate mentoring and support. Many 

specialist, an ejqierienced programmer without object skills, technology architects are simply not well equipped to handle 

and an inexperienced person. Note that this 1/3 ratio rule the tutoring, coaching, and communications demands inher- 

only applied to the team doing implementation. Thus, even ent in component-based development, 

though the total team size was about 200, only 40-50 were Avoid starting inexperienced people in architecture roles, 

doing hands-on implementation, implying the need for about There are simply too many skills to leam. Architects need to 

13-17 skilled people. have a deep knowledge of design patterns, programming 

Another engagement found the best mix to be one expe- languages, technical infrastructure, and methodologies. It is 
rienced developer to every four or five new developers. This 20 better to start new developers in application development 

project had a weU-defined architecture and used \lsual roles where they may have the opportunity to view the 

Basic to develop components. The relatively short learning architecture as a consumer. TTiis perspective may make them 

curve of Visual Basic aUowed this project to further leverage more effective in future architecture roles 

Its experienced developei^. While the dual role of building and supporting an archi- 
S^"^ ContracUng External Component ^5 tecture exists in a traditiond client/server^emTit may be 

In some cases, independent contractors have proven an ZZ^^^^^Zt^"^ vTT' '''Y''^^' Component- 

effective sohition for fiUing gaps with specific niche skills. ^ ^^^t^ ^^^^ ^ higher degree of coordmation by the 

Experience has shown, however, these p^ple may not be work developers partly because more application 

businessHoriented, adapt weU to the structure of a large developers may be mexperienced with the environment, 

engagement, nor have experience with mission-critical However, even an experienced team requires extensive 

development. coordination, because a greater level of consistency is 

Another problem has been having to fight object religion required, 

wars. Developing with component technology demands more 

Managers must Adopt New techniques, yet Not Forget consistency, because an application framework and business 
Fundamentals 35 or domain component model provide more reuse. In 

It's often said that, a good manager can manage anything. particular, much of the business logic may be shared by a 
Many management skills such as planning, monitoring common domain component model, viewed by many win- 
status, working with end-customer expectations, and man- dows. To strive for this greater level of reuse across many 
aging risk certainly apply to any domain. These blocking- business fuinctions requires coordination among many 
and-tackling aspects of management must not be forgotten 40 developers. The risk is that the components may not fit 
on a component-based development project. Managers may, together. 

at times, be intinaidated by component experts, and ignore This type of development approach requires a strong 
the basics of project management architecture vision that is clearly communicated and sup- 
Managing Iteration is DiflBcult, but Possible ported through training, mentoring, and documentation. If a 
In particular, object industry and academic gurus fre- 45 strong vision does not exist, then the components may 
quently suggest that object development and iteration simply inevitably not fit together into a cohesive, integrated archi- 
cannot be managed. Their recommended approach is usually tecture. In addition, this strong vision must include an 
some form of time-boxing the development, simply declar- understandingof the business objectives and functions of the 
ing victory whenever time is up. However, this represents a system to be effective. 

very un^pealing approach to promising delivery of busi- 50 Strong architecture direction must also be accompanied 
ness benefits to clients. Fortunately, experience has shown by a positive "bedside manr^r". y^plication window devel- 
that this does not have to be the case. Managing iteration, opers may often perceive a framework somewhat restrictive 
while certainly more difficult, is possible. of their creativity, too limiting, or burdensome, particularly 
However, software development managers must recog- when bugs hold up tiieir delivery. It's important for the 
nize that component technology has a pervasive impact on 55 frameworks developers to be service-oriented; and, to real- 
many aspects of the development process including ize that developing a reusable component is hard work and 
estimating, planning, methodology, and technology archi- requires iteration. 

tecture. For example, iteration impacts many of the standard Do Not Organize All the Component Skills on the Archi- 

rules-of-thumb for work completion. And the extensive tecture Team 

reuse of a common business component model requires 60 Because of the significant technical challenges often 

more sophisticated organization strategies. faced, a team may be tempted to staff all the experienced 

Managers Must Invest Hme in Training component developers on an architecture frameworks team. 

Thus, successful managers must be willing to invest the This strategy makes some sense. However, it should not be 

time to leam new terminology and techniques to adapt to followed to the exclusion of leveraging the application or 

these changes. Traits common to those who have success- 65 component modeling development team. Developing the 

fully scaled the component management learning curve functional business logic requires component development 

mclude: and methodology skills, as well. 



Category 


Basic 


Rinc 


Adv 


Analysis and Design 


4 Vfks 


6-8 mos. 


18-24 mos 


Implementation 


3-4 wks 


5-6 mos 


18-24 mos 


Frameworks Design 


16 wlcs 


12-24 mos 


24-48 mos 


Management 


3-4 wks 


12-18 mos 


24-36 mos 
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Staff an Engagement Team with a Mix of Backgroimds They distinguish the learning curve in four different skill 

Staffing an engagement with deep technical skills is areas as shown below, measured in months: 
clearly a challenge. However, the engagement team should 
not overlook the importance of functional skills. Experience 

has shown that technical backgrounds may sometimes be 5 
over-emphasized to the detriment of functional expertise. 

It is important to remember that many roles on the team 
are more demanding functionally than technically. Inter- 
viewing users, analyzing business processes, and designing 
the user interface all do not require extensive technical lo 
training. Moreover, not adequately understanding and ana- 
lyzing the functional requirements are the most expensive The above results are reasonably consistent with a user's 
mistakes. Research has shown that 70-80% of a system's experience on cHent engagements. Some experience sug- 
mistakes result from misunderstood requirements. gests that most firm personnel, on average, reach proficiency 
Component Technology Involves Multiple Learning Curves 15 levels slightly faster than the above figures. However, a user 
A component approach affects almost all aspects of the may experience a much larger deviation, both positive and 
development lifecycle. For this reason the component learn- negative, than that reported above. 

ing curve cannot be equated with a programming learning For example, some talented individuals reached a func- 

curve such as 'C. There are multiple, distinct learning tionally competent level in implementation skills in as Uttle 

curves that affect individuals at many different levels in the 20 as 8 or 10 weeks, less than half that suggested above. On the 

organization: other hand, about 10-15% of individuals did not ever reach 

Component and object-oriented concepts and terminology this level of expertise in a reasonable amount of time. 

Object analysis and design Experience has Identified Key Predictors of Success 

Programming language ^ noted above, a user may experience a reasonable 

Programming environment and other development tools ^ °^ personnel on engagements. 

(e.g., browsers, debuggers, user interface tools) Unfortunately, some chents have not been as successful. 

New architectures-such as how to use the project- rie^ F'fT"^ i,^"^"^ T ^""^ ^"""JJ^J^T: 

specific application framework P^?"^ .^f ""^^^f ^ '^^"^ 

^ , . . . , , . ^ , below IS drawn from a very smaU expenence base. As one s 

Managsment-suchas estiiDatiiigandplamnngforwoik. ^ experience grows, the list of traits may be refined with- 

and managing iteraUon and prototypmg hopefully-more objective measurability. This may be key to 

EducaUng management about the muIUple learamg hoping both a user and clienb to be more successful with 

curves helps manage expectations. It's also important to components 

avoid equating experience with pure elapsed time. For j^Q^y 

example, a person may be in the implementation phase 35 Component-based development requires a Mgh degree of 

doing things_unrelated to buUdmg their component skills change. Finn peisonnel deal with diange their entire career, 

such as creatog test conditions. Often, dient persomiel may not be as adaptive. They may 

Component Skills May Take linger to Transition to the have worked with the same structured methodology and 

, , . . . , COBOL for 5 or 10 years. To change their entire process can 

AS a re^t ottlie many eammg curves. It c^ take loi«^^ ^ be a big culture diift. Individuals must have the right attitude 

to sucoess&lly transition skdk to the chent. It is essential to ^ inteq,ersonal flexibility to change, llus fiictoTmay help 

have chent pMbcipation in <dl areas of the project to enwe ^ experienced people have often scaled the 

the transfer of dolls. One of the most effective approaches j^^j^ f^^, more seasoned developers, 

js to have chent personnel pair up with more expenenced Yet, the simple fact that someone has deep COBOL 

developers. Of course, this may be more expensive and may 45 experience does not mean that they may fail. TTiere have 

. . been several examples of people on ensagements who 

The Rate at Which Individuals Scale the Learamg Curve successfully made the transition Lm COBOL to Smalltalk, 

anes idely ......... , ^ , inchiding architecture roles. However, all of these individu- 

Expenenoe h^ shown that mdividuals scale the learning ^ ^ere highly motivated with an open mind to change, 

curve at very d:fferent rates. Auser may have good succ^ 50 On the other hand, migrating to C++ may be a consider- 

with indmduals becoming producUve in a reasonable ^ble chaUenge for people who do not have experience with 

amount of tune. In some cases, people have learn«i apointer-basedlanguage.That is, C++ projects should favor 

^'^'"^^^^^'1^ °° ' ^"^^ ^^""^ ^^'^ staflBng people who have minimally programmed in lan- 

erable ddficul^. . • ,- ^ guages such as C or assembly language. 

Auserul model of the expected learmng curve is outlmed Quick Study 

by Goldberg & Rubin [3]. TTiese results are based on thei^ Component technology involves multiple learning 

extensive expenence trammg peisomiel, pnmanly m the curves-people may need to lean, fast, lliey must be moti- 

i P™"^ ^^""^^ proficiency ^^^^ self-starters, capable of learning quickly on their own, 

?• - . - . willing to read and perform supplemental tasks to 

Basic-Capable ofdomg basic assignments with adequate ^ improve their competencies, 

supervision, usually attained after formal training and Communications Skills 

some experience with simple assignments Component-based projects are very social endeavors. 

Functional-capable of doing most assignments with a Because any given business function requires several col- 
predictable level of productivity and minimal supervi- laborating components, developers also have to collaborate 

65 with one another. To ensure that components integrate 

Advanced — an expert resource cq)able of solving very smoothly, and to achieve the desired reuse, a high degree of 

difiBcult or unusual problems communications and teamwork is necessary. This is signifi- 
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cantly difFerenl than many traditional systems where a after initial skills are developed. This generally requires a 

sj^tem is decomposed into larger, monolithic modules. fair degree of commitment from experienced frameworks 

These modules are typically developed front-to-back by developers to provide mentoring. 

each developer in relative isolation. A Formal Certification Process Supports On-going Skills 

Creativity — ^Experience with Custom Systems Development 5 Development 

Acomponent-based development project requires creativ- Since component technology can result in many new 

ity. The overall atmosphere is usually very challenging with ^ competencies, an ongoing, comprehensive skills 

fewer, concrete rules. The answer to many analysis and assessment and certification process has proven beneficial. A 

design decisions is, "it depends". Similarly, the development certification process defines areas of competence and then 

environments encourage exploration and browsing. lO ^^}''^^y evaluates mdiWduals' capability and progression. 

Work Ethic ^ extend across design and coding skills to include 

Individuals must be motivated to undertake personal ^^"^^^ ^^h portions of the architecture. Peoples' skills 

training. There often is not enough time to supportall the If^^!^^ compulsory design and code revle^^. In 

^ . . ^ J • 1 1 t_ r J'i^" effect, this becomes a component-Specific skills evaluation, 

trammg needs dunng normal work hours for the system to ^ ^ certification prc)cess hel^ to: 

meet a reasonable schedule. Thus, at times, mdividuals must is ^^^^ rigorously identify and d^-be competencies of 

pursue personal study and expermientation after hours. This % ^^^^^ in terms of skills Ld compe- 

type of commitment reqmres enthusiastic, hard-workmg tence; and, what habits should be discouraged and 

mdividuals. flagged as performance problems. 

ImUal Trammg Requires Handsnon Case Studies to be Xrack peoples' growth-it encourages improvement by 

Effective 20 challenging people. 

ImUal training reqmres significant upfront investment provide a more effective way to assign appropriate roles 

Project Eagle achieved very good results with then- multi- to people and offer up the opportunity for people to 

week Eagle Umversity. Unfortunately, this represents a grow into a more challenging role as quickly as they are 

larger amount of upfront time than many engagements can adequately prepared. 

reahstically support. In addition, timing may be difficult, 25 Support more effective communications of what 

because often project team members may roll on the project resources had which skills (e.g., through a wallchart) 

at different times. Summary 

Thus, many engagements may need a more flexible model Component-based development requires more time to 
with training time staggered in smaller chunks. For example, scale the learning curve, because it has multiple dimensions, 
the training may be accomplished through some combina- 30 Component technology skills cover a wide-range of com- 
tion of formal classroom training done in waves, seff-study, petencies including analysis, design, programming, and 
case study experience with mentoring, reading, and on-the- management. Thus, leveraging expert mentors and skills, 
job training. The key point, however, is that a significant investing in adequate training, and ensuring continued sup- 
commitment to training must be made-whether done upfront port are all key to success, 
or spread throughout the project. 35 Team Organizations and Roles 

There are several other lessons learned that can be drawn This chapter discusses the team organization and roles 

from the Eagle experience. Perhaps most important, training involved with component-based development, 

should be based on case studies. It should involve a signifi- Manage the Team Size with Care 

cant degree of leaming-by-doing including both design and Team size should be managed carefiilly. Component- 
coding exercises. Examples can be taken from the actual 40 based development involves difficult coordination overiiead. 
application to be built, thus reducing the perception of pure This stems from the higher degree of reuse and greater 
training investment. However, care must be taken to ensure modularity of the system. A greater number of common 
that day-to-day project demands do not detract from the components are reused across business functions. In 
training. For example: addition, components are smaller than traditional modules. 
Simple examples from well-known domains (e.g., check- ^5 Thus, more work from multiple people must integrate 
book application) ensure that the application require- smoothly. This complicates increasing the team size, 
ments do not bog down the learning process. ^ * project slips off-schedule, caution should be exercised 
People may need to be taken away from the project site, ^ adding people. Brook's fundamental law states: 
or firewalls created, to enable a total immersion envi- Adding more people to a late project makes it later, 
ronment. ^ underestimate the impact more people have on 
Individuals* should work in teams to simulate the collabo- <^'^ation and communications. Start-up costs can also be 
ration necessary on an engagement. sigmficant. New developers may have a leammg curve. 
, . r L f. . , experienced developers must learn project-specific 
If real portions of the apphcation are used, the team aspects such as the framework, business requirements, and 
should manage expectations so as not to confiise train- 55 team structure. These initial costs not only impact a new 
mg goals with producing deliverables. team member's productivity, they also reduce experts' avail- 
Reuse should be taught and encouraged through exerdses ability for mentoring others. 

that force the developer to browse. Manage Expectations Regarding Developer Productivity 

On-going Support is Necessary for Developers to Scale the Industry Gurus Have Created Unrealistic Expectations for 

Learning Curve 60 the Required Team Size 

On-going support is necessary to help developers con- The need to manage team size must not create unrealistic 

tinue building skills. On-going training is important because expectations for developer productivity. High expectations 

the entire development hfecycle is affected, to some degree, have been fueled by many object industry experts who 

by the shift to components. An individual's first few assign- recommend a dramatically smaller team. Many have sug- 

ments should be carefully planned to enable growing skills, 65 gested that as little as 80-90% fewer people can accomplish 

and to identify people who demonstrate aptitude. Time must an equivalent amount of work as a traditional development 

also be allowed for scaling the productivity learning curve, team. 
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However, experience does not support these exaggerated quality and consistency reviews for object model 

claims. Initial engagements have incurred considerable start- behaviors implemented by window developers 

up costs such as training, architecture development, and frameworks team members developed the overall archi- 

bu^mg reusable components. mechanisms, providing Wuctuie and default 

Some compelhng evidence suggests object/component 5 behavior for the entire applicaUon. 
technology can unprove productivity enough to reduce team 

size later in the software development lifecycle or for server team members developed common data access and 

subsequent projects. Brooklyn Union Gas cut their mainte- service routines on the server, 

nance staff in half and still accomplished as much or more Architecture roles must be defined to support this greater 

work. Other firm experience has shown d>ject technology degree of specialization. One engagement used the foUow- 

reduced system test effort, enabling a smaller team. Large ^° partitioning strategy: 

engagements have also realized benefits of reuse, signifi- Functional architect-responsible for resolving decisions 

cantly reducing development time for windows later in for what the system should do. This person is ideally a 

development. However, none of these experiences reported user with a solid understanding of systems, or a systems 

an order of magnitude reduction in team size. person with a good understanding of, and relationship 

Use Components as Work Packages users. 

^S^tcZi^Sv^wI^^^ the risks of a Technology architect-responsible for delivering the 

large project is to simply avoid being large. Partitioning a platform, systems software and middleware mfrastruc- 

project into analler sub-systems is one way to reduce size. ^ f° support execution, development, and operations 

Component-based development is particularly well-suited to 20 architectures. 

partitioning the development effort because the constituent User interface architect-responsible for setting direction 

components can map directly to team responsibilities. This of ^^ser interface metaphor, layout standards, and 

simplifies division of responsibility and roles, because soft- integrated performance support (IPS), 

ware and team organizations can mirror each other. Application frameworks architect-responsible for 

For example, FIG. 44 shows a high level picture of 25 designing, delivering, and supporting the application 

application component interaction for an Order Entry sys- framework that provides the overall structure, or 

tem. The boxes represent the application components of an template, of the application. 

appUcation being developed. Orders are fulfilled by inter- object model architect-responsible for identifying and 

action with the Product, Customer, and Warehouse Apph- resolving modeHng issues necessary to achieve a high 

cation Components. These software appUcation components 30 degree of business reuse and modeling consistency, 

can then serve to define the structure of teams and their Note that the last two roles are especiaUy unique to 

coUaborations with each other. object-oriented and component-based systems. This means 

Keep m mmd, however, the benefits of this partitionmg these architects have a learning curve to simply understand 

approach may be influenced by the degree with which these ^hat their role means in the organization. Furthermore, the 

components mteract. Thus, determining the appropriate 35 architecture roles require the deepest technical skills and 

granularity of the components is a key, strategic design shouM be staffed with the more experienced resources on the 

decision. project. 

Greater Specialization of Roles is Necessary One must be very careful in ensuring that appHcation 
Two recent engagements mvolved very large teams, in frameworks are not "over-architected". Experience has 
one case peaking at over 200 people working with object- 40 shown that many frameworks fall by the way-side for the 
onented technology. In both cases, the engagement teams simple reason that they were not built closely enough in 
leveraged expertise m a manner somewhat similar to a conjunction with the application development. They become 
traditional engagement There were, however, important too theoretical, compHcated and over-engineered making 
differences in scalmg object-onented development to such a them performance bottlenecks and obstacles to simplifying 
large size. 45 application architecture. It has been found that frame- 
One important distinction is the categories of expertise to ^orks should "fall out" of the application domain as can- 
be leveraged. For a traditional engagement, most developers didates become obvious. Experienced developers that wodc 
tend to be divided in two basic categories-^ctional or closely with the appUcation can quickly identify repetitive 
technical. These two dimensions represent the primary types constructs and abstract useful frameworks from this context, 
of leveraged expertise. That is, guidance is provided by 50 Data and Object Model Architects Must Qearly Define 
functional and technical experts. Their Roles 

Component Development Requires Functional, Technical, One issue that must be resolved early on is the relation- 
and ModeHng Competencies sjiip between the role of the data architect and the object 
A component-based project adds a third dimension— model architect. In traditional development environments 
modeling. The skiU set to model and represent behaviors and 55 data architects produce deliverables such as Entity Relation- 
relationships in components and objects is a distinct, com- ship diagrams. Since an Object Model is a superset of an E/R 
plimentary skill set to fimctional and technical skills. Thus, diagram, it is important to avoid treating the two as separate 
most projects find that they need a third type of expert— e.g., entities because this can lead to development teams working 
a component/object modeling architect(s), to provide direc- from two separate schemas. Viewing the d?ject model as the 

60 object and data schema is very helpful in solving perfor- 

Four primary onHne development roles may be defined: mance problems later and in promoting an overaU under- 

window team members developed the window-specific standing of the information schema of the system. 

functionality. Their role was biased towards consuming One strategy that has been shown to work is to include the 

rather than providing common object behaviors, senior data modelers in the object modeling team and give 

although there was some degree of the latter. 65 them appropriate object modeling training for their roles, 

object model team members developed complex behav- This allows a natural migration of the object model to be the 

iors in the common object model; they also performed logical schema for the database model. However, this must 
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be carefully managed so that good object model principles This approach offered the following advantages: 

arc not violated by a strong-minded data modeler who has aligned with the object architecture 

not transitioned through the paradigm shift. . , . ^ . 

Greater Collaboration Between Roles is Necessary cross^fimction consistency and reuse of business 

Another distinction is the necessary coordination of roles 5 

due to the impact reuse has on the organization. In a supported developing and leveraging specialized exper- 

traditional architecture, modules tend to be larger front-to- tise 

back slices of functionality. Reiise is primarily confined to However, the following drawbacks were experienced: 

technical services. Thus, functional developers can work over-the-wall problems in coordinating hand-oflfe of work 

independenUy, relatively peaking. The greater degree of amongst multiple developers 

reuse in a component architecture, on the other hand, ^^^^ing work direction to people became more compU- 

requues much more coordmaUon of effort. *^ ,u 1 1- j , . ^ 

The Organization Stmcture Must Enable Specialization and ^^/^ '^^'^ ^^"^ P^^'^^ 

CoUaboration P^''.^^"' 

Component development requires a more sophisticated managing completion of business functions becomes 

organization structure to support the increased specialization nearly impossible 

and collaboration of roles. Specialization is generally more ^ Workcell Organization Combines the TWo Approaches 
important because more is being custom created- and less of illustrates a workcell organization approach 
the answer is codified as a proven sohition. As noted above, inchiding an activities component 4702, a credit/collections 
weD-defined roles are also important to ensure reusable component 4704, a billing component 4706, and a finance 
components fit together. 20 component 4710. This approach combines the two previous 
At the same time, the stmcture must enable adequate approaches into a workcell. The primary orientation can be 
collaboration of team members. Too many specialists may aligned either way, but a functional orientation seems more 
result in an organization that requires extensive coordination natural for a business application. A cell is comprised of a 
to deliver anything— e g., a completed window. The orga- complete set of specialized skills such as functional analyst, 
nization must then strike a balance between "vertical" ^ object modeler, application architect, and even user. Cross- 
partitioning by function and "horizontal" partitioning by architects then provide specialized direction for a par- 
architecture layer. This is a classic management problem at ticular role. 

an enterprise or project level. This approach, while adding complexity to the organiza- 

Vertical Partitioning by Business Function Better Supports structoe, has been used successfully on a number of 
Collaboration ^ engagements, and has been shown to combine the benefits of 

FIG. 45 illustrates a traditional organization structure approaches. Of course, a drawback is simply an 

including an activities component 4502, a credit/collections ^^^^ ^^^^^ organizational complexity— e.g., individuals 

component 4504, a billing component 4506, and a finance ^ taking direction from two different people, 

component 4510. This traditional organization for most Additional Effort is Needed to Ensure Consistency Across 

projects is vertically organized based upon business fimction Workcells 

with a technology architecture team. In this organization Additional effort is needed to ensure that each workcell 

model, there would be one or more developers that are develops application components in a consistent manner. It 

responsible for building a business function end to end. This ^ important to define development standards and entry and 

works well for the following reasons: criteria for all workcells. In addition, it can be useful to 

aligns well with the business process and software decom- have a single person or group perfora:! design reviews across 

position project 

enables clear work direction-i.e., complete a window or , A workcell's architect or frameworks developer can also 

report, front to-back P apphcation developers better understand the architec- 

ensures that complete functions work in an integrated. n?'*."* " «>iisistenUy. Furthermoie the woAceU 

f^.u:^„ architect serves as a good channel to feed new 

end-to-end fashion . * i_ j » - . • ^ , 

, ^ „ . , requirements — based on the application developers 

teams better align to apphcation releas^ experiences^ack to the architecture team. 

However, there are ^veral potential shortcomings with Management May Need to Plan for at Least One Major 

this approach for an object-oriented system: Re-organization 

may force developers to leam multiple aspects of the 50 The most effective approach depends on die team size, 

framework (e.g., user interface and persistence ^lative experience, and even the phase of the project. The 

services) which does not enable as much specialization dependence on development phase impUes that management 

01 skiUs jjjjy jjgg^j pi^jj jgj^gj jjjjg reorganization, 

doesnoteasily support consistency and reuse of business Unfortunately, re-organizations create significant team 

55 dismption, which must be considered, 

does not readily enable cross-function leverage of exper- Workcell Organization May be Influenced by Other Factors 

lise Some additional guidelines include the following: 

Horizontal Partitioning by Architecture Better Supports Spe- Larger teams generally need to favor increased 

ciahzation specialization, because they may almost always have a 

Several object-oriented engagements have tried an alter- 60 higher proportion of inexperienced developers. Thus, the 

native horizontal, or architecture-based, organization. FIG. specialized model supports developing areas of competency. 

46 provides an illustration of a horizontal organization Early in an engagement more specialization may be 

model 4600. In this model, one or more developers are required as an infrastructure of common components and 

responsible for a horizontal layer of the system. Teams may frameworks is constructed. 

be organized around layers such as technology architecture, 65 Once components are stable and integration of function- 
frameworks, user interface, component/object model, or ality is more important, then a collaborative, fimctionally- 
data access. aligned or workcell organization may make sense. 
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Hie higher degree of custom development required in the Summary 

architecture, the more speciaUzation of skills is necessary; Crafting an organization structure for a component-based 

likewise, the more stable the architecture, the less important project involves balancing many complex factors. The most 

IS ^alization m favor of supporting collaboration eflfective approach may depend upon the size and ddU set of 

Complex, non-staiidaidprdjlenasl^^^ 5 the team, the architecture structure and sUbility, and even 

lend themselves to mcreased coUaboration. On the other , ^^e application. Some additional co^iderations 

hand, more standardized problems can be solved with the include- ^u^iviviau^/u^ 
specialized model. This experience is also consistent with 

management research of macro-organizations for an enter- Regardless of the chosen organization, care must be taken 

prise. *® ensure walls do not build up between teams 

Woikcell alignment may be influenced by the needs of the People's behavior may be influenced by the organization; 

client. If the client's objective is to develop a highly reusable that is, research has shown that the organization model 

business component model, then it may be appropriate to ™ay be reflected in the software architecture. For 

have a single team focused on developing the component example, one engagement experience may shown that 

model. On the hand, if the client is most concerned about individuals may allocate behaviors to inappropriate 

delivering business functionality, workcells should be components to avoid having to collaborate with other 

aligned by business function. developers 

The Organization Must Support Informal Structures Workcells combine the benefits of horizontally and ver- 

Whatever the formal organization, the project must enable tically aligned organization structures, and have been used 

extensive informal commimications. Component develop- successfully on a number of engagements, 

ment requires a tighter coupling between functional and Planning and Managing Development 

technical design, because more commonality is incorporated This section discusses strategies for managing a 

into the architecture as common services. Thus, few impor- component-based development process. Two alternative 

tant decisions can be made solely by one group within the development strategies are: 

project 25 Waterfall Approach 

One large engagement combined several different strate- Iterative v^proach 

gies to ensure effective communications across organiza- Much of the one's experience may be with large, mission- 

tional boundaries: critical projects. Moreover, large projects introduce 

cross^ceU weekly integration meetings were used to dis- additional, inberent complexity. Therefore, these issues may 

cuss and resolve low-level issues of global concern 30 be discussed primarily from a large project perspective. 

temporary, cross-cell teams were formed to address many A Tension Exists Between the Waterfall and Iterative Devel- 

special issues — e.g., integration with an external opment Models 

system, an approach to handle addresses, etc. The Waterfall is the Traditional Approadi to Managing 

temporary scout teams were formed to pflot the approach Software Development 

for a global change before rolling out to the entire 35 Systems development traditionally relies on a waterfall 

team — e.g., the migration approach for moving sub- model. This approach manages development in sequential 

systems into system test. phases of activity such as analysis, design, code, and test. 

It's also important to consider the importance of informal The waterfaU model provides a controlled, orderly process 

sharing of information when many developers are undergo- for developing a system. Work is sequenced to ensure that 

ing training or there are global architecture changes under- 40 the design addresses the correct requirements, implementa- 

way. Geographic splits of a team can cause special problems. tion is based on upfront design, and system testing verifies 

Roles are Changed for Persoimel at Multiple Levels and validates thoroughly unit tested components. 

There often is not a direct mapping to the traditional roles Despite these benefits, the waterfaU model introduces 

that individuals expect. Analysts and Consultants may be potential problems. For example, 

given tasks with less creative fitcedom than they expect For 45 Requirements may be difficult for the user to undeistand 

example, an Analyst lole may mvolve less cvstom coding ^thout prototyping the user interface or fiincdonality 

and more reusmg, assemblmg, and testmg of components. j • l 

Design tasks for a new Consultant may also seem overly The design team may not be prepared to specify an 

restrictive, because the challenge is to do things in a much ^^^CH^^ design without gaimng unplementation expe- 

more consistent, standard maimer as dictated by the frame- 50 nence 

work. A not be positioned to generate reusable 

On the other hand, because everything is often so new to components for itself, unless a team works ahead to 

the entire project team, in some ways everyone is starting construct an architecture or component model during 

together from scratch. Thus, in a few cases, very talented design phase 

Analysts with prior component experience have assumed 55 Iteration Helps a Team Address Risks and Gain Experience 
lead technical design roles. Because of the above shortcomings, much of the 00 and 
Traditional Hand-offs Between Designer and Coder are component community recommends some variation of itera- 
Problematic tive development, in which analysis, design, and coding 
The way roles work together is also different. For activities overlap to some degree. A theme in these varia- 
example, because of the iteration and coupling required 60 tions is the need to address risk by proceeding ftuther in 
between design and code, hand-offis from designer to pro- development sooner. Both the gained information and expe- 
grammer generally do not work weU. One scenario used to rience can influence the approach taken in the current phase, 
leverage skills involved a lead designer creating the design. However, iteration also has drawbacks. The team may slip 
prototyping the solution, and stubbing-out methods with into hacking, by simply skipping design before coding. Or, 
comments. The details were then flushed out by a junior 65 a team may use iteration as an excuse to not exercise due 
developer. Leveraging by review and mentoring has also diligence in completing tasks. Defining and estimating mile- 
been key. stones is also hard. 
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A Project Must Weigh the Tradeoils Between Waterfall and Iteration Does Not Scale Well Due to Communications 

Iterative Models Overhead 

Thus, a tension exists. The waterfall promotes discipline Aside from these psychological considerations, large 

and control in the development process. In contrast, iteration projects introduce significant risks due to the complexity of 
proves out assumptions, gains advance experience, and 5 coordination. A large team has a much greater inertia, 

addresses risks. Balancing these conflicting goals is difficult because of the time delay and errors introduced in human 

on a large scale. conmiunications. Any change takes much greater effort and 

Distinguish Between the Macro and Micro Process in the time to implement. Correspondingly, once made, changes 

Workplan are more difficult to reverse. Greater reliance on documen- 

Both the waterfall and iteration have pros and cons. A tation is often necessary to avoid miscommunications. 

hybrid capitalizes on the advantages of both. If they are Many decisions must then be considered from the vantage 

merged, one or the other must inevitably dominate the point of their ease of communication. This complicates 

structure of the high-level project plan. That is, the plan must iteration. For example, if analysis, design, and code overlap 

start somewhere — either by defining iterations or waterfall- extensively, then by cfefinition, requirements and design 

like phases of completion. change later in the process. Cbmmunicating wide-scale 

For example, defining iterations of the system or sub- changes late in development can be inefficient, wreaking 

system would result in high-level project phases such as: havoc on existing code. Thus, iteration does not scale well 

first working version macro level, because of communications overhead, 
refined woridng version 20 . '^'^ important to re-state, however, that a pure waterfall 

nil J 1 • • introduces many problems for component development due 

final, released woAmg version to its mtrmsic reuse and newness. TtS^ many of the lessons 

In contrast, a more traditional waterfall structure would .i „u* r** *l l 

w LLi I - .L L below emphasize variations of iteration and how they can be 

result m high-level project phases such as: ^^^^^ ^ ^^^^^^j approach. 

requirements defimuon ^ Incremental Development May Help Manage Scope and 

preliminary design ^j^k 

detailed design and/or coding Incremental Development Partitions the System Roll-out 

testing into Releases 

A macro plan reflects the high-level development phases Perhaps the most effective way to mitigate the risks of a 
The micro plan shows the tasks of a q)ecific phase or team. 30 large project is to simply avoid being large. Incremental 

Distinguishing between a macro and a micro process development addresses risk by reducing the necessary team 

provides a practical compromise. The pure, traditional size and scope. "Incremental" and "iterative" development 

waterfall has no distinction. There, the entire workplan and are often used interchangeably, but they are different 

accompanying development approach sequence analyzing approaches. 

everything, then designing everything, then coding and 35 » * i j t * *i. * ti . 

^ y *Sr 1 ^ *r * Incremental development partitions the system roll-out 

tesung everythmg, with no overlap. TTie same umformity successive releases. For example, the initial release of 

between macro and micro processes applies to a pure ^ ^^^^^ ^-^^ ^^^^ processing, fol- 

1 erauve model. In this case, the workplan reflects multiple ,owed by a subsequent Sease for bUling, and a third i^lease 

iterauons of the entire apphcation However, in either case, coUections processing. Tlius, incremental development 

siK^h extremism ^ not necessary, 40 functionality, while iterative development con- 

the two approaches by distmguishmg between the: ^^^^^^ ^^^^ ^^^^ fimctionality. 

macro, high-level plan, and Incremental development is often more palatable to man- 
micro, phase or team-specific plan. agers than iterative development, because there is no explicit 
In summary, an exclusively waterfaU or wholly iterative notion of repetition. Yet, the desirable benefits of iteration 
model are, independenUy, too simple. A balance is required. are often realized. For example, releasing consecutive ver- 
Distinguishing between the macro and micro process gives sions of the system creates the opportunity, and often the 
management the intellectual freedom to craft a worlq)lan requirement, to refine the initial release. The early imple- 
that reflects a mix of the two styles. The downside is that this mentation experience can also provide important productiv- 
mtroduces significantly more effort and complexity in the ity benefits for subsequent releases. This experience may 
planning process. also help drive out technical requirements for future 
The Macro Process for Large Projects Should be WaterfaU releases, improving the analysis and design process, 
in Nature Incremental development avoids the complexity of a big 
Managers are Averse to Iteration, because it Expects bang integration. Furthermore, although an incremental 
Re-work, ipso facto 55 approach delivers less in each successive release, it can 
The previous section laid out two alternatives for com- deliver higher priority portions of the system much earlier 
bining the macro and micro process. For large, custom ^ traditional approach, thereby recognizing business 
development projects, experience has shown that defining benefits in a shorter time frame. 

the macro process along the lines of a waterfall structure is Despite these benefits^ incremental development is not a 
most effective. Client and firm project management are 60 panacea. Many times a big bang conversion has proven 

typically uncomfortable with defining milestones and esti- necessary, if the cost and risks of having paraUel systems 

mating work with iterations. The common statement is, and bridges, performing conversion, and rolling out training 

"How do I know when I finished the current iteration?" This are high. These costs must balance those introduced by the 

concern is valid — on a large^ale, "complete" can be dif- delayed delivery of business benefits and the risks implied 
ficult to define. In addition, most managers have trouble 65 by increasing scope and team size. The uirgency of the 

embracing a process that expects and even allows mistakes business and the desire to manage development size may 

on such a large scale. sometimes favor an incremental approach. 
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Incremental Development Can also Apply to a Single Dcvel- Architecture Development Must Start Early 

opment Release A Tension Exists Between Use Cases and Frameworks 

Even when incremental development does not prove As with client/server, architecture work must start early, 
feasible for entire application releases, the approach can be As noted above, this is particularly challenging because of 
effective on a smaller scale. For example, the development 5 level of application reuse in a well-designed application 
and release of a single application may require extensive framework and domain component model. Because of this 
integration of diverse behaviors in a reusable domain com- reuse, the framework must be heavily driven by application 
ponent model The domain components must be put in place requirements, or use cases. Yet, the architecture team must 
early to allow reuse; then, behaviors are ino^mentally added °f application development teams to 

as the business use cases are analyzed and designed. As in lo f "sure that the architecture and component model are ready 
the previous case, iteration naturally occurs; but, again, in time to be reused. Thus, a difficult tension exists between 
incremental proves to be a more acceptable metaphor. ' ^ frameworks. 

Enable Top Down and Bottom Up Development . tension between use cases and frameworks can be 

Different Categories of Tasks should Proceed at Different simplified to the extent that third-party or standard archi- 
Rates 15 lectures such as Eagle can be leveraged. In addition, expe- 

Whether applying a more waterfall, iterative, or incre- nenced architects may bring their knowledge of whidi 
mental process, the dependencies between tasks require services are common across applications and can be 
careful consideration. Different categories of tasks need to addressed earlier than application-^)ecific architecture ser- 
procecd from problem-definition through solution at differ- ^° ^he foUowing guidelines should be 

ent rates. 20 *^°sidered, particularly for custom architectures: 

FIG. 48 illustrates the Enterprise Information Architecture architecture should be defined and prototyped, if 

(ElA) model 4800. This model adapts to component necessary, early in the preliminary design 

terminology, with the relatively minor change in layer five The architecture should be coraplete-al the very least, the 

from data architecture to domain component model. development architecture and overall framework, prior 

Both Top-down and Bottom-up Models arc Necessary 25 to developers actually coding; the design must be in 

This model incorporates the idea of simultaneous top- place earlier when functional developers start detailed 

down and bottom-up development. Much development design; private architecture aspects may be deferred 

effort may follow a relatively top-down, sequential Time must be planned for architecture support based upon 
approach. This includes analyzing and designing: the busi- unforeseen use cases, performance tuning, documenta- 

ness environment and processes, domain model, and then 30 tion and developer mentoring 

application. Concurrently, an architecture effort proceeds Developing a custom application framework should be 
bottora-up. This builds: the technology architecture of plat- estimated as a set of tasks in addition lo much of the 

form system software, hardware and infrastructure services; traditional technology architecture development 

and then application architecture, or frameworks. Top-down Failure to Develop the Architecture Early May Reduce its 
and bottom-up efforts then conceptually meet in the middle, 35 Efficacy 

integrating the application framework with die application. If the architecture is not completed ahead of the 
Both the Architecture and Component Model Lead App]i- application, developers may have the tendency to build 
cation Development architecture services in the application layer. Qearly, this 

The need to start architecture implementation early is may lead to diminished reusability and more difficult main- 
well-understood for traditional or component-based client/ 40 tenance. By defining the architecture services early and 
server development. What is different with component- conununicating them clearly to the application teams, these 
based development, however, is the need for the component problems can be avoided 

model to lead the application and user interface develop- A related problem with object architecture and frame- 

works is that the line between the application and architec- 
Starting the component model early is essential to 45 ture can become bhirred. These architectures may provide so 
enabling reuse of a consistent, cross-functional set of busi- much common fimctionahty that it is difficult for teams to 
ness components. These core domain components must be distinguish who is responsible for what For example, it may 
defined early, at least in preliminary form. Otherwise, the not be clear that a function should be provided by the 
simxiltaneous integration of functionality from many win- apphcation architecture team, technology architecture team, 
dows or reports would be extremely chaotic. In addition, 50 or application team. This problem can be resolved by better 
developers may implernent business logic in the user inter- communication and coorxiination across teams. Workcells 
face layer, rather than in the business components where it are one approach that has proven effective in this area, 
can be reused. Furthermore, early design of the component Component-Based Development Requires More Granular 
model before user interface logic improves the odds of Milestones 

creating a pure component model, decoupled torn the 55 The Macro Process Uses Traditional Milestones 
mterface. The milestones used to track the macro process generally 

Design Efforts Should Focus on Component Interfaces remain the same as for traditional systems lifecycles. Project 

Interfaces are the contracts for the services that a com- management may still be interested in monitoring the 
ponent provides. Clients of a component are concerned with progress of high-level milestones such as the start and end 
what the interface specifies, not how it is performed. It is the 60 of design, or the start and end of construction, 
interface provider that is concerned with the implementa- The Micro Process May Use More Granular Milestones 
tion. By correctly defining interfaces during design, it is On the other hand, the micro process may have more 
becomes possible to independently develop components. granular milestones than traditional systems. Whereas a 
When interfaces arc changed, component assembly becomes business function in a traditional system may be composed 
much more difficult and rework is often required. Thus, 65 of single front-to-back module, a component-based system 
design efforts should pay additional attention to the com- may provide the business function using several coUaborat- 
pleteness of interface verifications. ing components. Thus, component-based systems inherenUy 
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have more work objects to track. While the increasing During implementation, detailed design and coding steps 

number of work objects may seem to be a management may overlap. However, the rules and guidelines for sequenc- 

burden, it can provide a more fine-grained reading on the ing these should be spelled out in rigorous detail. Note that 

development process. this does not imply iteration per se, although that may be a 

Another difference from tradition^ systems is that mile- 5 desirable side-effect if controUed. Rather, this approach 

stones may be more onented around elements of the systems ^^erely suggests tactically interspersing the design a^d code 

some types of milestones may be more important than ^""JfT t^u . t . 1 

others. For example, if there is a significanramount of Concrete A^estones with Short Intervals 

functionality in the business components, then there may be ^° important difference in managing efforts with this type 

more milestones associated with the business components overlap is the need to define much more concrete mile- 

than with the user interface. stones with shorter intervals. This is necessary because a 

The Micro Process Should Vary with the Type of Develop- detailed design or coding phase definition loses meaning if 

ment Role ^hey overlap extensively. Milestones represent more 

The Micro Process Must Compliment the Macro Process concrete, visible accomplishments, such as: 

Assuming a waterfall-like macro process, as described all basic layout and behaviors designed; complex behav- 

above, the challenge of the micro process is incorporating an iors identified, but not completely designed 

effective level of iteration into this management framework. a i- *• ji - * * j • 11 

T^ or * 1 r * u view and application model integrate with domain model 

Different roles for team members require different devel- a ui^mmu luuu^^i 

opment methodologies. For example, possible roles are: 20 window opens 

y^lication developer— responsible for implementing a access firom server coded and tested 

particular business function, such as accepting bill fidl detailed design of special processing or complex 

payment. This focuses on the application-specific behaviors 

design and implementation tasks such as: working with complex behaviors coded and tested 

a user to define requirements or use cases, designing the 25 Incrementally Add Behaviors to the Reusable Cbraponent 

user interface, and implementing application function- Model 

^*^* A previous point emphasized starting the component 

Component Model developer— builds, refines, and sup- model development early, because many of these compo- 

ports the core, reusable business components in the nents are reused in many business functions. Thus, their 

application. 30 preliminary structure must be available before multiple 

Frameworks developer-responsible for the application windows require their use. This implies that many different 

and technology architecture that provide common ser- behaviors may need to be continuously integrated into these 

vices and control logic for the appHcation. components over and over. The component model 

These roles do not necessarily correspond directly to development, then, is very much event-driven like a factory, 

organization assignments. Whether these roles formalize as 35 Incremental is a Good Term for Continuous Integration of 

teams, identities within a workcell, or possibly different hats Behaviors in the Component Model 

a single person wears is an organization decision that The salient feature of this development style is that 

depends on the project size, individual skill sets, and other behaviors are incrementally added to the reusable compo- 

factors. nent model throughout the development. Iteration and 

Within the Micro Process, More Parallelism Can be 40 refinement often occur naturally in this process. However, 

Achieved incremental proves to be a more acceptable term for man- 

At the micro-level components make it more reasonable agement. 

to execute more development tasks in parallel. Components When developing in this fashion, tracking status is difS- 

enable this by providing more discrete work objects that are cult. Management traditionally tracks status by number of 

more clearly separated by their interfaces. Because inter- 45 windows or reports complete. Yet, in this style of 

faces are the contracts through which components interact, development, the windows complete may fluctuate dramati- 

the internals of a component can be developed indepen- cally. Some windows may not achieve completion until very 

dently as long as the interfaces are re^)ected. late in the project, when the component model sUbilizes. 

Dependencies on Shared Components Need to be Managed Yet, many behaviors may indeed have been completed. This 

On the other hand, since some components may be reused 50 creates an illusion that the project is further behind than 

throughout the application, it is a good idea to start them reality More sophisticated status tracking is therefore 

earlier to provide a solid base for the rest of the system. needed. 

Thus, a greater dependency on certain reusable components Iterate to Address Risks or High Degrees of Uncertainty 

may require additional planning effort to correcfiy sequence Prototypes "Buy Information'* that Reduces Risk 

the work. 55 Iteration is required to address risks involving a high 

i^licadon Developers Can Follow a Relatively Formal, degree of unknown. These risks tend to increase with 

Sequeiitial Process component-based development, primarily because of its 

A significant portion of application development can novelty. Thus, the need to iterate is often less intrinsic to 

execute in a sequential manner. This excludes the develop- component-based development and more related to chal- 

ment and maintenance of the core component model and 60 lenges naturally resulting from unfamiliarity. What is now 

application frameworks discussed below. For the application "traditional" client/server development faced similar diffi- 

developer driving out requirements, design, and implemen- cutties years ago. 

tation of window fiinctionality, development can proceed In some cases, this unknown requires experimentation, 

very similar to that of a traditional, client/server GUI For example, a throw-away prototype has the explicit intent 

project Particularly early in development, many aspects of 65 to "buy information" for reducing risk. Prototypes are a 

the methodology can be very similar such as CAR (Control special case of iteration involving less commitment to 

Action Response) diagrams. salvage the work Whether the prototype is salvaged or not 
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becomes less relevaDt, because the primary value is in the very high degree of iteration, such as technical prototypes or 
information obtained in the process. development of reusable components, should be confined to 
Several different categories of risk require iteration. None a small team of experienced developers. These individuals 
of these are unique to component-based development But usually comprise the architecture frameworks team, 
they tend to be more important with component technology 5 One heuristic is to staff the frameworks team with the 
because, again, so much of the underlying technology and most experienced component developers, comprising about 
methodology are new. Some of the types of prototypes are 5-10% of the total team size. There is another reason to 
(Ihese are similar to other definitions): allow the most skilled developers to iterate more— research 
usability, or user interface prototypes has shown that very experienced software developers natu- 
performance prototype jq rally work more productively this way. Thus, productivity 
proof-of-concept prototype for very talented architects may increase when given free- 
pilot process prototype dom to iterate as necessary. On the other hand, anecdotal 
These categories may be addressed with throw-away evidence tells us the opposite is likely true for inexperienced 
prototypes, initial working models which are later refined, or developers. 

some combination. Use of "prototype" below generically 15 is not to say that application developers should never 

refers to either style. iterate — ^it*s really a question of degree. One approach is to 

User Interface Prototypes Help Users Understand Require- ^ selected application developers on scout teams that form 

ments for one-time efforts and then disband. These efforts may, for 

User interface prototypes address the difficulty that users example, address an initial pilot process or other type of 

have in defining requirements without implementation 20 Prototype mentioned above. Even then, these efforts are 

examples. This phenomenon is analogous to the Heisenberg tisually best coordinated by an experienced developer, pre- 

Unoertainty Principle. This law of modem physics states that sumably from the frameworks team, 

the simple act of trying to observe the position or velocity of Difficult Tasks Plan Three Iterations 

electrons affects the result itself. Likewise, users' percep- aspects of the system that require iteration, the 

tions of their requirements may be changed, sometimes 25 Question still remains. How do I know wbtn I am done? 

dramatically, by observing examples of the potential solu- Experience has shown that three iterations are usually 

tion. In many cases, these prototypes have been used as a required, for example: 

standard design deliverable with repeated review and refine- design and develop initial working model 

ment with the user. refined working model and pilot 

An important consideration, however, is scope control. 30 roll-out and support 

There is a very complex management problem when itera- The need for three iterations has been observed in so 

tion is used to drive out requirements with users. Experience many cases that some consider it a magic number. For 

has shown that users may assume that exploring an alter- example, the three iterations defined above parallel very 

native implies that the functionality may be implemented. closely a maxim quoted by Kent Beck, a well-known 

Thus, some change control procedures need to be defined 35 Smalltalk expert. Make it run, make it right, make it fast, 

and managed, even if they do incorporate some flexibility to Difficult Components Should be Designed and then Proto- 

incorporate enhancements. typed 

Performance Prototypes Address Global Architecture Issues An initial working model phase designs and prototypes 

Performance prototypes primarily address technology the component or framework. Prototyping may be necessary 

architecture questions. For example, the architecture team 40 to evaluate two or three alternative approaches. In these 

may need to decide early on whether to use messaging, cases the initial design represents a strawman, until receiv- 

remote procedure calls, or shipped SQL statements for ingvalidation from implementation. Only then can things be 

distribution services between chent and server A prototype finalized and reviewed for sign-off. 

is often the only way to identify the most effective sohition. Piloting Reusable Components with Developers is Neces- 

Proof-of-HConcept Prototypes Address Complexity 45 sary 

Proof-of-concept prototypes address areas of significant Ehiring the refinement and piloting phase, the component 

technical or functional complexity In the most extreme case, or framework is completed with any remaining funaionality 

the team may be uncertain as to whether they can even and then used in a pilot case. Coordination is often necessary 

develop the logic within the specified quaUty parameters. Or, with a pilot developer who is a client of the reusable piece, 

it may be too difficult to design a solution upfront, because 50 to ensure that it works in an appropriate use case. Typically! 

of a mix of technical, functional, and maintainability issues. the pilot process generates several refinements or changes! 

In such cases, the team may need to implement alternatives Pflot developers need a flexible, positive attitude to handle 

for evaluation. potential instability. 

Pilot Process Prototypes Provide Experience for the Team The component must then be documented arxi rolled out 

Pilot process prototypes are used primarily for the team to 55 for reuse to all developers. In many cases, the roll-out 

gain experience. They typically use a front-to-back, slice of requires a formal group meeting to answer questions. During 

the application. This is similar to incremental development, the support and refinement phase, the component is refined 

which delivers the solution to a portion of the business as other use cases generate new requirements, and bugs or 

functionality Such learning benefits are not unique to pilot performance problems are identified. Although the imple- 

prototypes. The distinction of a pilot prototype, however, is 60 mentation details of the component should not be widely 

that gaining experience is the primary purpose of the effort. known, it is critical that developers thoroughly understand 

The learning may focus on technology, business function, or the purpose and public behaviors of the component. If they 

methodology. do not, then they may not be able to effectively reuse and 

Confine Highly Iterative Tasks to Experienced Framework debug interactions with it. 
Developers 65 Summary 

Iteration demands very experienced developers, to under- A traditional client/server implemenUtion often incorpo- 

stand the criteria for completion. Thus, tasks that require a rates some limited iteration with a waterfall approach. This 
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iteration is usually confined to technology architecture tasks. In fact, several stages of integration must occur to complete 

Component-based systems tend to require somewhat greater a single window. 

iteration for three key reasons: Consider a customer that encapsulates other related corn- 
Reusability often requires actually reusing the component Po°cnts such as credit profile and address. This customer 
to ensure the reused piece meets requLments 5 ^gg^gation even represents too much functionahty for an 
J- 1 mitial component test. Sunpler components such as the 
Component technology is new, thus iteration helps address must be tested first. Testing individual components 
address greater technical risk or tightly coupled aggregations should occur in the initial 
Component skills and methodologies are emerging, there- component test phase, 
fore the team often gains valuable experience from assembly phase then tests the integration of these 
iteration components. This test phase differs from a traditional assem- 
Managing iteration is difficult but possible. UsuaUy the test because rnore components must typically be 
planmustin^rporateah SJ^^^^^ 

iterauve models as appropnate. TTie nght process depends integration of interdependent windows in a dialog. In 

on the orgamzation or teams* skdls, the degree of technical contrast, a traditional assembly test concentrates much more 

risk, and the specific application and business requirements. heavily on the horizontal dialog test, since the front-to-badc 

Testing window functionality is often just a single module. 

Testing typically consumes anywhere from 50-80% of The timing of the assembly test may vary depending on 

development effort. Despite this relative importance, testing development teams organization. If there are a number of 

receives little emphasis by component-based developers working on a functional slice of the application, 
methodologies, which focus primarily on analysis and ^ then early mtegraUon helps to eiisure that developers are 

design techniques. ™s sec^on p..nts testing' le^ns ^c^^^.^^^^^ oT^TaSo" 

consistent with the priinary themes m TTie Testmg Process cant if a single developer is working on an entire bu^ess 

Practice Aid, produced by the Re-mventmg Testing Project. fimction, end to end. 

These points merit increased emphasis, however, because In summary, the collective atomic, component, and 
experience has shown component-based systems increase ^ assembly test phases require much more detail in terms of 

testing complexity. milestone definitions, status tracking, and methodology 

Testing is More Complex development. 

While a component-based approach may be simpler to Testing Component Collaborations Must Occur in Several 
test than a strictly object-oriented approach, testing is still 

more complex than a procedural system, because component ^ , J^^ process of testing and integrating behavior of col- 
architectures* laboratmg components must occur at multiple levels. In 

decompose into a much greater number of components ;.^nK^^^*^^ ^"^^^^ J?'. !^^P°°'a' 

^ . , , , , , - . J. • assembly test phases can seem somewhat arbitrary. A well- 

thaneqmvalent procedural modules, mtroducmg more factored architecture may have identifiable boundaries, 

complex techmcal mtegrauon achieve a greater level of however, as noted above. Thus, coming up with good 

reuse, which is a blessing once highly reusable pieces definitions of aggregation— that is, cohesive groups loosely 

stabilize, but remains a substantial challenge while they coupled from other groups, is equally critical to testing as to 

undergo development design. The component aggregation must then support an 

utilize flexible, messaging between components that ere- effective partitioning of the application architecture and 

ates a larger number of potential test execution paths ^ team organization, 

usually develop with some degree of iteration, which Testing Requires a Flexible Organization 

jeopardizes the benefits of phase containment 9° ^^^^ projects, the set of components involved in a 

Testing Requires More Phases business event are often developed by many different 

Hie Testing Process defines a three-step process, very People. Thus, the complexity of team integration further 

similar to traditional Method/I, as foUows: complicates the testing effort WeU-defined component 

„ . ^ ^ * * r • J- -J 1 J 1 Dounoanes m the software and organization are certainly 

t '^'f^'' k^y- organization i^ust expect the need t^ 

gram that is specified and coded as a single unit ^^^^^^ flexible integration testing teams thTform to ensure 

assembly test— a test of a set of programs that commu- a particular business function works correctly across parti- 

nicate with each other via messages or files, usually tions. 

equivalent to a user interface dialog or a batch string so Testing Effort Shifts Earlier in Development 

product test — a test that verifies the technical and func- The System Test Phase Should Go Faster 

tional implementation supports the business process The imphcations of greater modularity and flexibility 

Object Systems Require an Initial Atomic Test Phase discussed above increases complexity in the atomic, com- 

When building components using objects, testing can ponent and assembly tests. Once the architecture and highly 
logicaUy follow these same three primary phases, at a high 55 "reusable components in the component model stabilize, 

level, preceded by an initial atomic test phase. An atomic test however, system test is simplified. Thus, component-based 

phase is required because a weU-factored object system may systems require shifting testing effort earfier in the devel- 

typicaUy have at least 10 times more objects than procedural opment life<^cle. , 

modules in a traditional system. This finer ^anularity Containment Reqmies Greater AttenUon 

requires testing andintegratingmoremiitsatmult^le levels. 60 ^^^Z°^ ? fi T ^^\^^^^^^^^^ mcreaangly 

n^rr.^\^^^^ , D • « o I e* f ^ expensive to fix later m the development cycle. Phase 

Completmg a Wmdow Reqmres Several Stages of Compo- containiient strives to decrease both the numbe/and cost of 

nent T^t and Integration ^ ^ ^ , . . ^ fixing errors, by testing steps early in the development 

Atraditional approach often defines the mitial component lif^cyde through verification and validation of work FIG. 

(unit) test as a workmg window, front-to-back. In a 49 illustrates a V-model of Verification 4900, Validation 
component-based architecture, on the other hand, a window 65 4902, and Testing 4904. Exit criteria might involve, for 

may often utilize behaviors of several components. This example, compulsory detailed checklists or code reviews 

results in too much integration for an initial component test. before work is promoted to the next phase. 
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While phase containmcDl is not unique to component All of the above considerations result in substantial 

development, its importance is heightened. Since many re-testing. Enough so, that a manual approach to regression 

portions of the component model may be reused by literally testing can be extremely cumbersome. In particular, changes 

every window developer, quality is critical. That is, a high to shared components or changes at or near the root class of 
quality design and implementation for core components 5 a deep inheritance hierarchy can have widespread impacts, 

increase the productivity of every developer, however, the Thus, automated facilities for testing should be considered a 

converse is also true — mistakes tend to penalize all devel- mandatory element of component development, 

opers. Thus, thorough testing and attention to quality in early Combine Automated Testing Wtth An Automated Build 

development steps is important. Process 

Iteration Complicates Phase Containment lo Automated testing can also make the configuration man- 
Yet, incremental or iterative development complicates agement process more efficient. By using an automated test 
phase containment. Phase containment presumes a waterfall process to verify that the latest version of the application is 
model. For example, a module or component should not be working correctiy, it is possible to give the development and 
passed to a later phase such as coding imtil the design has testing teams more stable releases. For example, simple 
been validated and verified. In contrast, overlapping design 15 defects such as incorrect interfaces can be detected before 
and code imphes coding starts with an incomplete design. the application is even distributed. 
This puts at risk any efforts to define precise milestones so GUI Scripting Tools Alone are Usually Not SufiSdent 
critical to effectively track progress. Capture-playback GUI testing tools have proven effec- 
Iteration Requires More Detailed Exit Criteria tive. However, for many applications these are not com- 
Thus» iteration requires more detailed completion criteria. 20 pletely sufficient. These tools may only re-validate that the 
For example, different iterations of design must have very application appears to function properly. Experience has 
explicit scope boundaries to ensure that the completion of an also shown that applications may sometimes use widgets or 
iteration is adequately defined. These must be accompanied technical elements of the user interface not supported by a 
by strong adherence to proper procedures as components are particular tool, 
promoted through various development stages. Even with 25 Self-testing Features Should be Built 
such efforts, however, experience has shown that later A more comprehensive testing framework should be 
designs tend to impact previously working code. Significant considered that incorporates the notion of seff-testing com- 
regression testing must be expected, as discussed below. ponents. That is, the component may have behaviors, or 
Automated Regression Testing is Usually Necessary indeed contain a tester component, that feeds the class a test 
Regression Testing is Necessary Because of Iteration, 30 suite, and validates the resulting behavior. Note, however. 
Inheritance, and Extensive Reuse that test components rarely test behaviors of just a single 
Experience has shown that the higher degree of reuse in component in isolation, because any meaningful behavior 
an component model and application framework makes it usually cuts across multiple components. The test can still 
very difficult to protect implemented components from obey enc^sulation, though, by testing the group as a single 
subsequent development. Developers must then verify pre- 35 black-box, rather than taking short cuts which may under- 
viously tested components as they incrementally add func- mine the validity of the test, 
tionality to the system. Automated regression testing can Testing Frameworks Requires More Attention 
save time by ensuring that areas that are impacted by The use of frameworks in component-based systems also 
changes are properiy tested. increases the complexity of testing. Frameworks add com- 

Moreover, regression testing capabilities are absolutely 40 plexity for the following reasons: 

es^ntial if an extensive architecture fiamework is devel- Foreseeing all the uses of a frameworic is hard a priori, 

oped. Component-ba«d develcymem allows an apphcation Thus, verifying correct behavior is difficult because the 

framework to abstract both technical and ftmcUonal behav- test cases may not be complete, 

lors. This greater level of reuse necessitates that the frame- * * i_ ■ . ^ , 

work evolve with the development of the application. 45 test approach can require extensive scaffoldmg to 

Unfortunately, this imphes changing the technical environ- ^^"^ emulatmg the apphcation mtended to use the 

ment of the application even as it approaches delivery. To ewor . 

effectively support these enhancements requires re-testing at Framework development is usually undertaken early in 

many different levels. project so that it is ready to support apphcation 

Using Objects Increases the Need for Regression Testing 50 developers. This implies incomplete knowledge of 

When developing components using objects, regression requirements for the frameworks team, 
testing becomes even more important. For example, inher- stakes are high, because the framework usually 
itance often results in sub-classes coupled to their parent. A provides a reusable structure for many developers, 
parent class may have side effects with subtle implications There are essentially two methods for testing a frame- 
to children, which are difficult to identify for test cases. 55 ^oi^- 

Experience has shown that even seemingly innocuous Emulation approach — by building a comprehensive test 

changes to a parent can damage previously tested sub- environment that emiUates the ^plication. 

classes. Pilot approach — by using application developers as pilot 

In general, an inherited feature must be retested in the users in the testing process, 

context of the subclass. Retesting can only be avoided if 60 The emulation approadi protects apphcation developers 

subclasses are "pure" extensions of their superclasses; that from the testing effort, and is generally more consistent with 

is, if they don't override any methods and do not modify a formahzed approach. Not doing so opens the door to 

inherited instance variables. Furthermore, test cases usually rolling out untested frameworks. On the other hand, creating 

cannot be inherited when overriding a method. Shght dif- a redundant simulation environment of the apphcation use 

ferences in logic and data declarations are indeed enough to 65 cases can be expensive. 

invalidate the superclass' test cases, requiring new test The pilot approach may be more productive by leveraging 

definition and input data. real application code. In addition, it encourages training and 
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knowledge transfer to developers. Finally, it helps ensure deliverables completed in previous phases. In addition, there 

accurately covering requirements. It is important to use is a strong desire to link deliverables and requirements fiom 

application developers for the pilot, not the architects. Tins the earlier phases to the deliverables from the subsequent 

may provide an objective review of the framewoik's usabil- phases. 

ity. The primary drawback is that it takes a developer away 5 On a typical project one finds the following tools used in 

from the application; and, as noted above, may result in the software development process: 

frameworks developers feeling relieved from thorough test- General diagramming tools: Visio, ABC Graphics, etc. for 

mg. Experience has shown that a hybrid of the two is usually woricflow and operation diagrams 

necessary. OfEce: Wofd class and component specification 

r ' i_ t- .1. . • -x- 1 J, t templates. Excel scenarios, 
Expenence has shown that mitial component develop- 

ment projects require more eflbrt in testing. On the other ^^'J^^^ Oriented CASE tool: class and component models, 

hand, the later stages of testing can be more productive by component/class specifications, message trace dia- 

effectively leveraging encapsulation of components and grams 

large-grained components. There is reason to believe that is Database design tools: Erwin, Oracle Designer, etc. 

these benefits can be leveraged sooner if the team pays Integrated Development Environment(IDE): Visual 

increased attention to testing early in development Testing Studio, Visual Age for Java, JDeveloper, \%ual Cafe 

should be a part of the entire development process compris- Source code configuration manager SourceSafe, Qear- 

«Jg: Case 

phase containment principles with explicit objectives and 20 ^ inordinate amount of time is invested in the macro 

exit criteria such as checklists and peer or lead reviews process of how to capture and link information in a way that 

automated regression testing capabilities can be used effectively through the course of the project 

self-testing components » moving the models from the CASE tool into the source 

« J * 1 J 4 u J -t * code of the targeted IDE environment). Teams should tackle 

more detailed testmg phases and milestones -yc , ,3 rji* li • i. i_ ^""""""^""^ 

^ early the selection of deliverables m each phase and which 

comprehensive procedures with disciplined enforcement tool the deUverable may be created and maintained within. 

Development Architecture Considerations in addition, they should determine whether the deUverable is 

Ttus section highlights key messages for development to continue to be enhanced in subsequent phases of the 

architecture teams m regard to supporting teams and tools project through the iteration process 

wito a component based development project 30 Today's Dilemma ... No Easy Answers, Yet 

Building systems that arc dramatically more responsive to i- • . . ^ , , . . 

u • J 11 ' 1 . f_. To reahze an environment that enhances the productivitv 

change rcqmre a dramatically miproved development archi- „f ^^^^^ programmers is a challenge for any 

What does it mean to be more responsive to change? H^e P^^^^^' projects building component-based 

solutions one builds must be more^ 35 ^1"^°°^.^^ even more difficult becai^ of the technolo- 

^, , gys relaUve unmatunty. You won't find any easy answers. 

Flexible. Making it possible to replace or modify appli- y^t. 

cation components with minimal impact to the other n-„^,«ii„ *u n* - * * 

. ^ Generally speakmg, the resultmg environment gpts the 

components m me system. ^^^^^ consists of tools that are crudely integrated 

Scalable. Giving you freedom to distribute and reconfig- with no central repository. This results in redundant data and 

ure appUcation components to meet the scalabiHty manual cross-referencing. It can also cause problems during 

requirements of the client. the transition from Design to Construction y4 a gap that's 

Integratable. Allowing you to reuse the functionality always been difficult to traverse. Other typical concerns 

within existing systems by wrapping them as compo- include a tool's ability to meet usability, scalability, and 

nents within the new application. multi-user requirements. 

Adaptable. Giving you freedom to deliver an application Ideally what would greatly increase the productivity of 

to a variety of user types through a variety of delivery the development architecture is a seamless integration of 

channels with minimal impact to the application itself. tools in the workbench and the ability to "plug in" whatever 

Reusable. Making it easy to quickly assemble unique and appropriate for the capture and communication 

dynamic solutions from reusable components. so ^ particular deliverable. FIG. 50 portrays a development 

Cbmponent-based development pushes us forward on all architecture with a seamless integration of tools which can 

of these dimensions, and although it's relatively immature, ^ plugged in for the capture and communication of par- 

we're better off than we were before. Metaphorically ticular deliverables. Shown in FIG. 50 is the relation^ip 

speaking, we've climbed very close to the top of the between a process phase 5000, deliverables 5002, tools 

mountain that represents traditional development. The view 55 repositories 5006, and an infonnation model 5008. 

is satisfactory, but we know there is something better, so One solution center working on this architecture found 

now we're climbing the mountain that represents that the current state of integration with tools was so 

component-based development We have yet to reach the constraining that the picture in FIG. 50 had to be resolved 

top, but we're already higher than we were before. with many compromises for new component work. There 

On every component-based development project, teams 60 were many custom scripts created and manual processes 

spend time evaluating and establishing the environment in defined for leveraging the flow of information between 

which analysts and developers create the deliverables. A phases and tools. 

workbench must be established that expedites the flow of FIG. 51 shows a design architecture with the compro- 
deliverables through the different phases of the project In mises made for today's component construction environ- 
component- and object-based solutions, these phases are 65 ment. Shown in FIG. 51 is the relationship between pro- 
very connected. This is largely because each subsequent cesses phases 5100,deliverables 5102, tools 5104 and 
phase tends to be an elaboration and refinement of the storage 5106. 
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Key Considerations in the business-modeling phase to descriptions of classes in 

A development architecture should provide an environ- the construction phase. UML compliant CASE tools provide 

ment for component-based solutions that supports a team a number of the deliverables that most object methodologies 

through the Analysis, Design, and Construction phases of uses, however, there are ahnost always some deliverables 
the development process. It should also serve as a productive 5 that do not fit in the selected tool. There is also a discrepancy 

environment for the on-going maintenance of an application. with the CASE tools' ability to comply with UML due to tiie 

Conceptually it should integrate all of the necessary tools continuing evolution of UML versions, 

through an information model and most ideally through a UML has become so universal now that deliverables fix)m 

central repository. The following are considerations that all most methodologies form a superset or, in some cases, a 
component development architecture must consider. lO subset of the deliverables described by UML. In the case 

1. Support Custom Process. The present invention uses a where a deliverable is a close match to a UML deliverable, 
robust process for developing component-based solu- proprietary scripting is required to allow for complete 
tions. It includes deliverables that are above and beyond semantics. This scripting is also used to migrate ftom the 
the Unified Modeling Language (UML). Furthermore, CASE tool to other drawing or word processing tool. Pro- 
projects often customize it. The environment must pro- 15 cedures must also defined to effectively use the tool to 
vide the ability to extend the information model (i.e., the support the process. 

meta-model). Decide on Supported Deliverables Early in Process 

2. Versioning & configuration management The environ- Case tools in recent years have extended their ability to 
ment should provide the ability to version objects within support more of the life cycle and improved their ease of use. 
the common information model at any level of 20 In addition, some case tools have improved their integration 
granularity, keeping track of these changes over time. It with the Integrated Development Environments (IDEs) and 
should provide the same ability for composite objects produce some level of acceptable component code genera- 
(i.e., configurations of smaller objects). tion. It is important for the development architecture team to 

3. Scalability. The repository-enabled environment must be determine early exactly which deliverables may be created 
able to support hundreds of users simultaneously, and 25 in each phase of development, which tool they may be 
hundreds of thousands of repository relationships. It captured in and whether links between phases require 
should also scale downward, so that small project can use uj^ading deliverables as a result of the transformations 
it. This is a major criterion for usabihty. and/or enhancements from other phases. 

4. Query and impact analysis. As organizations begin to The team must decide how much they may leverage the 
maintain their own component-based assets, they must be 30 automated tools to support the build process. An investment 
able to analyze the impact of diange requests (e.g., in the macro infrastructure can lead to tremendous time 
where-used searches). The ability to trace requirements is savings as the construction process is siq)ported. The team 
also critical. needs to determine early whether they may "build" their 

5. Asset catalog (reuse). As orgaiuzations begin to reuse custom process into the tool or adjust the process to better 
existing assets, it may become increasingly important to 35 integrate with the tool. 

provide a catalog of components, frameworks, patterns. Development Architectures are Often More Heterogeneous 

etc. The catalog should make it possible to seardi for than Traditional Environments 

relevant assets in a wide variety of ways. It should also While traditional client/server systems typically required 

provide a means for applying fi-ameworks and patterns. one development tool for programming efforts, component- 

6. Code generation. The abitity to generate the application 40 based systems are often built using several tools and pro- 
structure from the model is essential to high productivity. gramming languages. The increase in tools is directly related 
Furthermore, this step should be transparent to the user. to the improved capabihty to integrate software components 
As far as the user is concerned, a change to the model is through interfaces that hide the implementation details. 

a change to the code. Typically, the more heterogeneous environments may be 

7. Desktop Tool Integration. The repository-enabled envi- 45 built upon the open CORBA technology, while applications 
ronment must provide integration between all desktop developed with JavaBeans or COM may tend to be more 
tools (e.g., MS OflBcc, \%io, 00 CASE tools, designers, homogeneous in nature. Thus, it is important to understand 
etc.) through component object models such as ActiveX. the technologies used as the effort to design a cohesive 
In addition, these tools must have access to the common development architecture may be impacted. Plan to spend 
open information models. 50 more time designing and buflding the development archi- 

8. Non-redundant storage. The environment should avoid lecture for a heterogeneous environment, 
redundant storage of information, whenever possible. Configuration Management 

Everything from training to documenUtion to active com- The advent of client/server has focused significant atten- 

ponents should be automatically updated or notified of tion on the importance of configuration management as key 

changes. 55 to success. Configuration management is more than just 

9. Multiple users and locations. Many users may need access source code control. It must encompass the management of 
to the environment during the course of a development the application software components from conception, 
effort. Furthermore, because one supports global commu- through implementation, delivery, and enhancements. While 
nities of practice, there is a strong need to ^are this the problem is not unique to component and object 
information securely and across disparate locations. 60 development, an object-oriented environment presents spe- 

A Development Architecture Needs to Support Customiza- cial challenges discussed below. 

tion of the Process Configuration Management is More Complex in a Compo- 

UML & Case Tools in the Development Architecture nent Development Architecture 

Each project using component-based technology deter- Currently, artifacts versioned with various tools do not 

mines how to use OO CASE tools to support an object- 65 know about each other. For example, an object versioned in 

oriented methodology and its deliverables. These detiver- a document management tool has no relationship to the 

ables range from high-level business process documentation source code configuration. In addition, various tools are 
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advertising the advantages of their repository strategies. Adopt a Philosophy for Configuration Management that 

However, these products are in their infancy and most do not Guides the Development of the Process 

integrate seamlessly with the source code configuration There are two fundamentally different approaches to 

managers let alone the various tools in a development configuration management in the component world. Simply 

workbench. Models, source code and documentation are not 5 stated, they represent the difference between an optimistic 

sjnQchronized. The reality is that current versioning in the approach versus a pessimistic approach to managing 

majority of tools only occurs at the file level and not at the sources. In the optimistic approach multiple users can access 

required level of granularity to support development ele- and modify the same sources and the tool is leveraged to 

ments. Methods, classes, components, and their respective resolve conflicts when code is merged. In the pessimistic 

deliverables should be versioned but only a few products on approach a source is locked when it is checked out. Both 

the market today support this level of granularity and they advantages have pros and cons and some source control 

are not yet mtegrated with popular case tool^ configuration to choose which approach 

Object Systems are Decomposed into More Pieces they may choose 

Configuration management is more complex with object ^^^ ^^ ^e Ownership 
development because the system IS more finely decomposed. ^ * a-.- 1 ^ v/^ruwoui^ 
Object development realizes the benefits of flexibility and 15 A ^aditional, procedural system usually assigns owner- 
reusability through a greater level of decomposition than by busmess funcUon. Functional developers take on 
was present in traditional systems. While smaller objects ^sponsibihty for a busmess function that corresponds to a 
have the advanUge of making it easier to have pre-defined front-to-back wmdow. Technical team developers then take 
building blocks, a disadvantage is that large-scale systems °° cross-function architecture rcsponsibihty. This approach 
have so many elements that managing their relationships 20 obvious benefits in providing straightforward commu- 
becomes difficult. nication points and division of responsibility. A drawback. 

For example, a key principle of object-oriented design is however, is that business function reuse is much more 

separation of concern, which decomposes behavior into difScult. 

smaller, more cohesive objects. This strategy strives to This approach breaks down due to the higher level of 

prevent changes from rippling through many objects. The 25 reuse in an object-oriented system. Note that a procedurally 

implication of this design approach, however, is that the designed system may also experience this problem to the 

resulting system may comprise many more modular pieces extent that the team strives for a large degree of business 

than a traditional architecture. ThLs greater decomposition logic reuse. 

complicates configuration management. Owners Must Exist for Every Versionable Cbmponent 

Not only are there more objects than procedural modules, ^ An object-oriented system must assign component own- 

the relationships and dependencies intrinsic to object devel- ership at multiple levels. Business process owners are still 

opment are usually more complex. For example, the rela- necessary; however, clear lines of responsftjility must be 

tionship between business processes and objects is a assigned for the domain object model. Often these two may 

complex, many-to-many mapping: a business process is have a tight relationship. For example, consider a gas utility 

implemented by more than one object; conversely, an object 35 customer system that provides customer service orders. The 

contributes to more than one business process. FIG. 52 service order business process and service order domain 

illustrates a business process 5200 to object 5202 mapping object owner should probably be the same person. However, 

to iflustrate such relationships between business processes the service order process may also need to collaborate with 

and objects. One manager referred to this phenomenon as other key domain components such as the customer and 

the web of interdependences. ^ premise. This requires collaborating and communicating 

To manage this problem determine early what the "unif* with other developers, 

of configuration may be and have the development organi- Rigid Ownership Boundaries May Not Work 

zation aligned with the approach. For example, in the Experience has shown, however, that the level of com- 

previous maze possible units of configuration could be: munications with core business objects such as customer and 

Process 1 depends on: 4^ bill account is so high that the rigid ownership might be 

Object 1 ineffective. The resulting communications of requirements 

Object 2 may produce inefficient hand-oflis and bottlenecks. For large. 

Object n mission-oitical applications, multiple levels of owner^ip 

This keeps the process component rigorously configured ™^ ^ defined. However, this creates a risk of 

with its dependent pieces. 50 conflicts. Before components mature, the rules of divisions 

Configuration Management Requires a Comprehensive should probably be more rigid. Later, multiple developers 

Approach can modify common classes, while keeping rei^nsibUity to 

Most Object CASE Tools do Not Support a Complete, release, or pubh^, the code in the hands of a single owner. 

Integrated Repository ' Thus, ownership roles may overlap, requiring the rules of 

Integrated tools have, thus far, not been found to support 55 engagement to be defined. Yet, every scenario cannot be 

cross-referencing window elements, object model attributes speUed out precisely. The team and leaderi^ip must then be 

and behaviors, and relational database definitions. Thus, participatory and flexible to adapt to the dynamic 

large projects must consider crafting a strategy to integrate requirements. 

multiple point tools to provide such cross-referencing. Large Engagement Defined Separate, Overlapping 

The tools gap raises the importance of rigorous procedural 60 ^^ership Responsibility for: 

and organizational models to address configuration manage- Windows 

ment. For example, proper procedures must ensure that Domain object model sub-systems, or components; the 

rigorous quality and build steps are followed before intro- model comprised about 350 model objects which were 

dudng a new component into the environment; the workplan partitioned into about 12 major areas 

requires much more ctetail to track dependencies; and, the 65 Business processes that were particularly complex, highly 

organization structure must effectively support more exten- reusable, and cut across many windows; for example, 

sive communications to react to changes. writing off a bill 
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CommoD architecture framework components The Object Model Must be Continuously Rolled Out to the 

Separate concept of ownership from developer for Team 

increasing productivity For object development, roU-outs of objects must occur at 

One solution to the above problem is the clear distinction varying intervals depending on the range of impact. Because 

between component ownership and developer rights. This 5 the object model is continually evolving as completed 

philosophy is supported by tools like Envy/Developer for windows incrementally add behavior, the model must be 

Smalltalk and Visual Age for Java. Assign owners of classes, continually refined and rolled out to the team . Some of these 

packages, and projects and then assign developers to the changes may have a very narrow impact to just one window, 

packages. Any developer may write methods on an open where others may have more global implications, 

edition or checked out copy of a class. The owner of the For example, changes may be rolled out in the following 

class can release the methods to the class, version the class intervals: 

and release to the general development team. In this model y^pUcation Interface or Cbntrol— nightly 

editions are open configuration units, versions are any units Narrow Impact Object Model-^nghtly 

that have been checked back m and releases are umts that , ^ * i-.u- j . , 

have been made visible to the next construct of configuration ^'^^ Model-coordinated on-demand, no 

management. 15 more than 1-3 tunes per week 

In this model clients of lower level components can be Frameworks^eekly or less frequent depending on 

added as developers in the integration phase. Rather than impact, maturity of the component, and the complexity 

have to wait for a new version of the component, they can of Ihe effort 

concurrently have an edition opened with which they can Structural Object Model — for Data Waves, Once Per Month 

modify or enhance and then submit their changes back to the 20 Object development also requires shrinking the i^elf lives 

component owner. This practice can keep control with dramatically. Reusable domain model and framework 

component owners but increase the bandwidth of the devel- objects generally require a zero tolerance policy for incor- 

opment cycle. rect code. Problems need to be fixed immediately, or at least 

y^4)plication Packaging must have a Qear Release Manage- their impact critically assessed and the fix scheduled. As 

ment Strategy 25 mentioned earlier, some of this immediacy can be managed 

To support a flexible ownership model requires a detailed with carefiil process surrounding ownerdiip, editions and 

technical packaging strategy. Multiple levels of granularity developers. In one tool there is a concept of a scratch edition 

for controlling source code are typically needed. The method that allows a non-registered developer to access units of 

and class arc obvious targets for versionable components. control and make changes within his private environment 

However, levels of granularity above the class are critical to 30 and still be able to post the changes back to the component 

properly control the cross-class development that occurs. developers and owner. This eliminates hours or day turn 

Typically development may occur on groups of classes around to correct a critical problem in a versioned compo- 

which can be versioned together as categories or appUca- nent. 

tions. In Java, for example, these categories are packages. Clean-up or Fix-it Days Must be Scheduled 

For example, the frameworics development team may gen- 35 Window or view specific behavior can have a longer shelf 

erally have a work-in-process version of the framework life, but still not as long as traditional development. Letting 

architecture package to support new development, i^plica- items sit for more than even just a few weeks can cause them 

tion developers would instead have an older version, typi- to become dangerously out of date. Thus, two different large 

cally the first version, that had been thoroughly tested and engagements found it necessary to schedule clean-up fix 

rolled out. 40 days on a regular basis. 

It may also be necessary to version groups of methods Regression Testing is Key to Effective Configuration Man- 
together in a class. This has proved beneficial for managing agement 

object model development. Regression testing is essential to support these more 
Components of the system should also have a well- frequent clean-up efforts. This approach frustrated 
defined [EWFl] relationship between them. This ^ould 45 management, because these days appeared to be a step 
occur at each level of granularity and give a definite feel for backward or treading water. However, keeping the applica- 
the dependencies between components. Each instance of a tion clean paid dividends in addressing and fixing problems 
component also needs to know the specific, tested compo- more efficiently. Generally speaking, the longer the problem 
nent versions with which they are compatible. It is essential went unfixed, the more expensive they were to correct, 
that the relationships between components are non-cycKcal so In summary, a flexible approach is necessary to coordinate 
or layered and that a complete dependency inventory be and control changes. Some considerations include: 
obtainable for every versionable component. Ability to absorb change— If the developers are over- 
Favor Shorter Shelf Lives to Support Frequent Roll-outs of whehned with change or learning curve, the shelf life must 
Reusable Objects be expanded to reduce change. 

One of the most difficult decisions for object development 55 Magnitude of the change — ^Minor changes may be easy to 

is how frequently to roll-out reusable components to mul- incorporate and may facilitate immediate turn around. Major 

tiple developers. And a related issue is how long component changes may be expensive to incorporate except at 

should sit on the shelf between changes. controlled, regular intervals. 

For a traditional, waterfall approach the shelf lives may be Restart Cost— Each effort to integrate changes into an 

quite long with few iterations. For example, a module is 60 existing component may incur a start up cost for the devel- 

typically coded and then put on the shelf until string test. The open This may again be influenced by the magnitude of the 

elapsed time ranges from a few weeks to many months. change, and the duration of the integration cycle. A rapid 

Likewise, once string tested the module may again sit for a integration cycle may keep the behaviors fresher in the 

long time until system test. These long shelf lives typically developer's memory; a longer sheff Kfe may involve a 

work reasonably well unless the underiying data model or 65 refamiliarization cost On the other hand, this must be 

architecture changes. In this case, unproductive re-work balanced against the cost of starting and stopping new 

results. development to implement fixes. 
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Stability — As a componeDt stabilizes and matures, the formance to a repository strategy (OMG's Meta Object 

shelf life can be reduced without impacting the rest of the Facility— MOF). These repositories, although encouraging, 

project. Unstable object components cannot be rolled out as are very immature and may require a few years to deliver on 

frequently, because the turn-around time is longer. their promises. In the mean time development architectures 

Delivery Capability— The ability of the migration team to 5 must decide on their own how they may provide the nec- 

provide a "most current" build may also impact the fix essary facilities to promote large team development 

versus shelf decision. In C++, the build process may be progress 

a major undertaking, where the shortest shelf life may Q^ery & impact Analysis 

be measured m days. In Sm^ta^^^ Tools are necessary to identify categories of similar 

rn.SefiL'n.'^^^ 10 behaviorsuchastheclasshieraichy,whereused,sendersof, 

to^karlydefinedpackagesimprovesA^ implementors ot etc. Today, many environments for C++: 

Configuration Management May Require 5-10% of Devel- Smalltalk, Visual Basic & Java provide robust browsers with 

opment Team comprehensive functionality. Additionally case tools 

Configuration management clearly requires more effort ^ provide search capabilities. Unfortunately every tool 

with object development. These roles are often hard to * different method for finding artifacts, such as text 

justify to management, because they appear to be pure searches for documents, menu provided searches in case 

overhead. The tasks may also appear unclear. For example, tools, and where used and senders of within browsers, 

tasks such as "Manage environment" and "Communicate As mentioned in an earlier secdon many of the language 

changes** do not to have a start and a finish. based IDEs provide sophisticated browsers and e^lorers 

These tadcs should be controlled and manag^ by a 20 that allow for searches for "where used" and "senders of for 

centralized effort. Several people sharing the effort in their messages and objects. These facilities are extremely impor- 

spare time may not exercise enough caution and due dili- tant in component leveraged architectures. They allow 

gence. Furthermore, a centralized effort may often result in developers to more effectively look for things to reuse rather 

automation of tasks producing significant productivity than always re-inventing what they need. One important 

improvements. 25 practice to help the searching process is naming standards. 

At least 5% of the development team should be com- They should be put in place early in the process to enable a 

plelely dedicated to the on-going configuration management principle ParcPlace was fond of calling, "the principle of 

effort. When setting up and defining the environment even least astonishment". Because of polymorphism developers 

more resources may be necessary. Of course, there are become very agile in locating classes and methods because 

limits. Stacking the team with too many resources may result 30 their interfaces are so common like all objects responding to 

in wasteful development of an overly elaborate tools archi- the "to String( )" method. 

tecture. One of the problems in current development architectures 

Another approach is to make the configuration process is the redundancy of the facilities. For example, rather than 

implicit in the entire development process. In other words, be able to rely on the repository where the information 

by ensuring that an owner of a class must version and release 35 should be stored in a conunon location developers may 

his work before it can be seen by a containing package the search in Rational Rose and in the source code manager for 

owner is required by the process to be thinking about the references of a given type. 

configuration process in all of his work. Subsequently, the One way to mitigate this issue is to publish information to 

package owner, generally a more experienced developer, a common location to make it accessible to everyone 

must ensure that all classes are versioned within his package, 40 through a common interface, preferably a web browser, 

version his package and then release it for general consump- Tools like JavaDoc and Microsoft Word (which can trans- 

tion. This would work the same for a project which tends to form documents into HTML) make it possible to leverage 

be centered around increasing units of capabilities (i.e. the web server's index server to locate artifacts from various 

business activities and finally whole applications). locations. This practice is being more widely adopted, as 

Scaling to Large Teams 45 shown by the release of IBM's JCentral tool. 

Despite the advice to use small teams, enterprise appli- Asset Catalog (Reuse) 

cations are large and often require in the aggregate a large One key improvement in component-based development 

number of developers. Development architectures must be from traditional development is the use of components to 

constructed in such a way as to support sometimes hundreds assemble solutions. Ibis is very different from libraries, 

of users with many, sometimes hundreds of thousands of 50 Because of the reflective nature of components, runtime 

development artifacts and their relationships with each binaries can be dropped into the development environment, 

other. their interfaces exposed and then integrated into the current 

All of the major software development tool providers (i.e. solution space. This is done through the Java Reflection 

IBM, Microsoft, Oracle, Unisys, etc) have announced mechanisms within class files and type libraries in the 

repository strategies. These repository strategies are much 55 Active/X world. 

more comprehensive then the proprietary repositories that Currently reuse tends to be at entire source code branches 

are represented by a source tool repository such as in Qear rather than component-oriented. This has been provoked by 

Case for source code or the proprietary repositories shipped poor version support in most development environments and 

with Case Tools or development environments like Envy tools inadequate for managing the assembly and configura- 

Developer and Forte. These repositories allow for informa- 60 tion of components into solutions. Some component man- 

tion to ^an tools and strive for integration between not only ager tools that are being released onto the market today 

tools provided by a single vendor or from a host of third support either the ActiveX or JavaBean component models 

parties as well. Many case tool and IDE providers have but its not clear how they may be received, used and 

annoimced support for this new generation of component integrated into development and design environments, 

repositories. 65 To maximize reuse requires the assembly and configura- 

The new strategies all espouse either de facto standards tion of run-time components in addition to being able to 

(Microsoft's Open Information Model) or eventual con- construct new components as part of the software construe- 
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tion process. A new breed of tools supporting black box This desktop tool integration strategy needs to take into 

reuse referred to as "Component managers" shoidd be account the comprehensive approach used by the configu- 

considered one of the primary took provided with the ration management strategies. In other words, relevant docu- 

environment to 1) support transformations between tools ments need to be associated with the components and 

where this may continued to be a requirement. 2) enable 5 business processes they update so that key stakeholders can 

component views of reuse allowing configuration from both ^ j^^^ 

run-tmie and development components and 3) give compo- ^f documentation neLl updating. TOs process may 

T ^tf'^^'^ prevenbng users from ^elp ensure that the publishing modd is dVnamic and 

modifying and/or reusing certain components if Ihey desire. ^ , y b ^'^w u> ujudimi. <iuu 

It requires the ability to categorize components and search f^°w*T j i.- , r 

components according to property descriptions in a way that '° ^^P^ Useis and Multiple I^Uons 

can be ascertained without the viewing of source code. Solution Centers and engagements often have many users 

Code Generation ^ multiple locations involved in solution delivery. It is 

In the past code generation was crude, had to be important for development architecture teams to solve 

customized, and was hard to keep synchronized once source *® problems of concurrency within tools and ownership 

code was emitted. This a\n^cwardness was caused by other across locations. Strategies need to be developed for how 

related factors like the lack of a common information model, components may be exported and imported, and supported 

little coupling with the IDE and no common repository across locations. In addition, an approach for receiving 

sources. In addition, the ability of the CASE tool environ- feedback for improvements needs to be established. Most 

ment to comprehend the run time environment was poorly projects have found that ownership is even more important 

supported in most tool environments. The most damaging 20 in a distributed development environment. Tliis allows for 

problem is the faihire of CASE tool providers to "own" the the using of master/slave assignments on components and 

code integration and generation produced from the model. dictating either who is allowed to make changes to the 

Some of the efforts to mtegrate with IDE's via Add-Ins are component or who is responsible for merging changes As 

a step m the nght direction but, some key issues, such as one technologist &om Sun stated, if distributed development 

idenuty integrity across multiple environments, have not yet ^5 is not managed carefuUy it can be like herding cats, 

been addressed to ensure its success. Summarv ^ 

That being said, code generation via case tools at the ai*u u t. n 

structural level can greatly increase the productivity of a ^f^l^ ^^'^ ^ challenges with development 

team when a rigorous model is adhered to in mappiig the ^ ^ component environment there are also 

domain model constructs to code or schema in the target ^ddiUonal opportumUes for mcreased productivity. A team 

environment. Two areas have been used to some degree of ^ understands the additional considerations may weigh 

success from component engagements 1) generation of DDL opporhimties that tool mtegration can bring to the project 

from object schema— the domain model and 2) generation against the practical gap in the market place and customize 

of the object structure or domain model to the target Ian- ^development architecture accordingly. Wise planning 

guage. and a clear understanding of the strengths and limitations of 

One analogy has been made with Layout Managers or ^ols available to a team may contribute greatly to the 

Screen Builders. A decade ago people were comfortable success or failure of a project, 

with coding windows by hand. Some even felt that form Managing Performance 

designers were too constraining and got in the way of Component-based technology is often sold on benefits 

developing a really usable interface. However, no one today such as reduced maintenance, increased reuse, or flexibility 

would think of generating forms by coding them by hand. So 40 to absorb change. Performance, on the other hand, is usually 

with the standardization of UML and the mahuing of object viewed as a significant drawback. However, resilience to 

model semantics developers should be reticent to code class change and performance do not have to be mutiiaUy exchi- 

structures by hand. Oracle refers to this as "one source of sive. 

tiiith". A change to the class structiire in the source code is Component Technology Can Enable Better Performance 

a change to the model and vice versa. 45 Component-based systems have advantages that can actii- 

Desktop Tool Integration ally enable better performance— but only if proper design 

Desktop tools today generally include an office suite, techniques are used. This chapter discusses the correlation 

drawing tools, case tools and more recently, a web browser, between perform ance-tunability and a well-designed 

For example, one might find a tool selection like Microsoft component-based system, and the implications this has for 

Office for documentation, Visio for custom deliverables, 50 project management. 

Rational Rose for models, and Internet Explorer for viewing The timing of ^en to address performance may initially 

HTML versions of the documentation. VBA has become the appear tiivial. "Design performance in from the start" is one 

glue for extending and connecting the information between often-repeated rule. The opposing viewpoint is expressed by 

these tools. Other strategies have included using Notes as a computer scientist David Knuth who said, "Prematiu^e per- 

repository for all of the deliverables that users could access 55 formance timing is the root of all evil". T imin g when to 

mformation. address performance is actually a complicated management 

ODM has many predefined deliverable templates that are issue. The competing forces and their possible resolution are 

targeted towards this suite of tools including Word, Excel discussed further below. 

and Visio templates. Often times management under- Define Performance Goals in Terms of the Business 

estimates the start up cost of integrating the tools in such a 60 An old saying goes, "Cheap, fast and good — ITl give you 

way as to improve the flow of information between phases two out of three". Many of clients may react negatively to 

and for ensuring that information is published to the team in this philosophy, because they would certainly like excel- 

a way that is accessible and plentiful. However project lence in all three areas. Yet, the fact remains that difficult 

experience teaches that this investment can yield many ti-adeoflfe exist between performance, quality, and the cost of 

returns down the road if the development architectiire 65 the system. For example, no one intentionally designs a slow 

inchides processes and infrashoicture to support this flow of system. Thus, it is critical to define performance goals in 

mformation. business terms based on cost/benefit analysis. 
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Consider service level agreements for online planned and conducted at the outset of the project. These 

performance, which are often based on the average wait time measures are important, because intuition may often be 

between screens. This makes sense in a technical environ- wrong as to where the problems lie. 

ment using 3270 display devices. However, this may lead to In addition, the technologies that make up the foundation 

poor busir^ss decisions for a non-modal, windowing GUI. 5 of a component architecture may be new and unproven. To 

A GUI may support a more rich set of processing than a minimize risks, look for a reference application that is 

3270-based design. This can result in response times much similar in complexity and size. If a similar application can't 

slower per window; however, the time for completing the ^ ^ necessary to develop a proof-of- 

business transaction such as a customer order may be concept prototype for the architecture. Such a prototype may 

equivalent or even less. Yet, to tune the performance for an lo ^^^/.f^ areas such as the middleware, application 

equivalent level of window-to-window J^ponse time may ^J^^^^^^' hardware platforms^ 

/ 1 . 1 . r™ ,f . / Performance is Balanced Against Encapsulation and Soft- 

simply not make economic sense. Thus, the requirements Distribution 

should be based on how efficiently the system completes the Performance is Frequently Balanced Against Encapsulation 

pure busmess event, encompassing potentially multiple ^nd Software Distribution 

windows, rather than a more technical measure of window- 15 as with any system, there are design trade offis that can be 

to-wmdow navigation. made to achieve better performance. With component-based 

Measure Performance systems, some of the most significant performance trade oflk 

Any effort to effectively address performance requires are made against encapsulation and software distribution, 

thorough measurement capabilities. There are two reasons The encapsulation of data forces applications to access 

for this. First, the team must understand where the specific 20 data through a component's interface. Unfortunately, encap- 

risks reside, before they can effectively attack them. Is the sulation may many times result in excessive messaging, 

application I/O or compute bound? Is database or network sometimes across a network, between components. Thus, 

I/O a bigger issue? Are there obvious bottlenecks? These are performance can often be improved by breaking encapsu- 

all key questions. lation to directly access data. 

Performance Metrics Focuses Attention and Provides Con- 25 Software distribution is often simplified by utilizing cen- 

fidence tralized application servers. However, a centralized 

Second, just the simple act of measuring and tracking approach may result in diminished performance due to the 
performance focuses attention in a positive way. Tools such network messaging. Performance can often be improved by 
as language profilers and memory-leak checkers are critical. distributing software closer to the point of usage. 
A rich set of tools can give the team more confidence in the 30 Selecting the right balance between performance, soft- 
quality of their development and technology. ware distribution, and encapsulation is not easy. Achieving 

Confidence is particularly important to object-oriented the right balance may be driven by system's requirements, 

and component-based systems development, because a deli- Performance Twining Can be Deferred with Object-oriented 

cate balance is necessary between addressing performance Frameworks 

risks without detracting from good object-oriented design. 35 Object-oriented Frameworks Enable Performance Tuning to 

For example, fear of messaging overhead may lead devel- be Deferred 

opers to avoid altogether factoring behavior into smaller Smalltalk columnist and consultant Kent Beck espouses 

methods and objects. Yet, such factoring is critical to appli- the philosophy "Make it run. Make it right. Make it fast." At 

cation reusability and quality. a glance, this advice may seem counter to the previous 

Fear of Object Messaging Overhead Can be Overstated 40 recommendation to address performance risks early. 

Apotential source of misunderstanding is equating object However, they do not have to be mutually exclusive. An 

messages with network or operating system messages. application should be prototyped — ^i.e., made to run, early to 

Actually, object message sends are often more comparable address broad architecture performance risks. Later, proper 

to function calls, albeit slower. And the overhead of message design should be the focus before performance, because a 

sends compared to function caUs can be unimportant com- 45 well-designed appfication enables more productive pcrfor- 

pared to the application I/O. That is, most applications are mance tuning. Optimized code is simply very difficult to 

I/O bound, not compute bound. On the other hand, it is maintain. And prematurely optimizing code may incorrectly 

important to understand the frequency of component mes- assume what problems are most important, thus wasting 

saging since it may cross network or process boundaries. effort. 

Thus, when looking at messaging characteristics it is impor- 50 Object-oriented system development, in particular, allows 

tant to distinguish between component messaging and for a deferred attention to performance. The component 

object-messaging. design goal of encapsulating implementation details tends to 

Address Architecture Performance Ri^ Early lessen the impact of major change to the application. This 

As with a traditional client/server system, performance allows sweeping changes to be made late in application 

risks should be addressed early. Performance requirements 55 development. FIG. 53 is a diagram which illustrates a graph 

often have a severe impact on the technology architecture 5300 of resilience to change. 

including the infrastructure design and the platform systems This graph illustrates the behef that through a good 
software and hardware. For example, the architecture team object-oriented design, changes related to performance tun- 
may need to decide whether to use messaging, remote ing may be made much later in the development lifecycle 
procedure calls, or shipped SQL statements for distribution 60 than would generally be possible with traditional structured 
services between client and server. Performance may also design. With an emphasis on good object-oriented design, 
impact fundamental platform decisions such as the choice of the degree of radical change possible late in development is 
language, DBMS vendor, operating system, network, or surprisingly high. 

hardware configuration. Non-object-oriented Systems Should be Pferformanoe Tuned 

Usually these parameters cannot truly be understood 65 Throughout Development 

without constructing a benchmark prototype. In cases where When components are not built using object-oriented 

the underlying platform is affected, the benchmark should be frameworks, it may not be as feasible to defer performance 
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tuning. Without frameworks that provide a well-layered and facing with, or maintaining that component. A fundamental 
factored architecture, it may not be possible to make small, grammatical naming standard is the means to ensure clear 

localized changes that result in dramatic performance communication between developers. This standaid must be 
improvements. Instead, it is better to performance tune as well-defined, strongly enforced, and supported by leader- 

the system is being built so that there is time to make 5 ship. 

changes. Furthermore, it becomes even more important to A weak standard of interface definition often results in 

establish design guidelines early in the project so that code requiring extra processing which could be avoided by 

detailed designs can be reviewed against them. This can help making assumptions based on a strict interface definition, 

ensure that performance problems are avoided before com- Performance tuning is easily complicated by generic inter- 

ponents are implemented. lo faces supported by vague assumptions. Redefining such 

Leverage Points interfaces late in development is often prohibitively expen- 

The value of reuse is frequently perceived as "less to sive relative to the low cost of clear initial interface defini- 

code". While often true, a sometimes overlooked, more tion. 

valuable aspect is "less to maintain". This is notably sig- An example of a poorly-defined interface is a method 

nificant when performance-tuning a system. It is generally 15 definition which may accept several unrelated types as its 

worthwhile to spend more time upfront determining how to parameters. The result leads to type-checking of parameters 

reuse existing components than it is to spend less time and decreased flexibility in tuning the implementation of the 

developing a new solution. Similarly, it is usually more method. The strong definition of interface parameters allows 

worthwhile spending more time generalizing a component fundamental assumptions to be made in tuning the imple- 

so it may be reused than it is spending time to develop a 20 mentation of the interface. 

specialized solution. A grammatically-based naming standard differentiates 

A Leverage Point is Factored Out Behavior that Enables between methods that do versus methods that get. In a 

Leveraging Global Performance Gains traditional approach, procedures or functions do routines 

A leverage point is processing common to multiple com- and algorithms. The unique blend of data and behavior in 

ponents which may be factored out and reused when needed. 25 component-based development, on the other hand, allows 

In performance tuning, these points are identified, profiled components to collaborate, asking each other for data, as 

andtuned, thereby leveraging any performance gains against well as directing each other to perform processing. This 

all components which use them. In general, the less actual requires the addition of nouns and the inclusion of verbs to 

processing an application-specific component (i.e. non- the vocabulary of interface definition. That is, the interface 

architecture) performs indicates the more performance 30 should specify what, not how. 

leverage may be gained from it by tuning architecture For example, if a customer component provides a public 

processing. interface that allows another component to ask it to query the 

For example, a business event controller class in a system database for its credit profile, a oonunon mistake is to define 

must somehow specify the relationships between its relevant a method getCreditProfile or retrieveCreditProfile in cus- 

business components and the widgets which may interact 35 tomer. If, however, performance tuning required caching the 

with them on the application window. There are two fiin- customer may already have the credit profile. This would 

damental approaches in specifying these relationships. The leave development with the choice of either changing the 

first is for an initialization method to be invoked in the method name in all referencing components, or create docu- 

controller which may perform the processing required to mentation to explain why the method getCreditProfile didn't 

define these relationships. The other is for that business class 40 really get anyiing, but just provided access to another 

to specify the bare minimum information required to infer component. 

these relationships such that a oonunon architectural com- This example illustrates the importance of naming to 

ponent can perform the actual processing required to define ensure encapsulation. The implementation changes required 

the relationships during runtime. to achieve radical performance improvements are feasible 

The latter approach provides a leverage point for perfor- 45 only through diligence in the pursuit of encapsulating imple- 

mance timing the initialization of the window. The process- mentation. Along with good design organization, clear inter- 

ing may be tuned to use a more ef&cient algorithm; the face definition is key in achieving valuable tunability. 

results of the initialization may be cached during application Limit Knowledge of Data and Object Relationships 

packaging and read during initialization; or, efiicient initial- Developers with structured programming experience 

ization methods may be generated and maintained automati- 50 often tend to perceive objects as data, manipulating them 

cally from the information by a code generator once it within the context of objects, effectively distributing behav- 

becomes clear what the most efficient implementation is. In ior associated within components amongst all the objects 

any case, the flexibility provided by this leverage point which interact with it. This becomes very difficult to per- 

allows many more possibilities to be considered during formance tune due to the combination of duplication of 

performance tuning. Note that all three optimizations could 55 code, and the wide impact any such tuning could have on 

be achieved without manuaUy visiting a single of perhaps application classes. A much greater degree of performance 

hundreds of windows which share the initialization process- tuning can be achieved when object responsibilities are 

iDg- respected and objects or collaborations of objects can be 

The pursuit of leverage points must be considered in tuned in isolation with minimal impact to their embedded 

every architectural design decision, and followed with dis- 60 system. 

cipline in application design. A simple example of "data-ifying** objects is when object 

Communication \^a Interface Definitions— ^Specify What A manages a group of other objects, yet other objects ask 

Not How object A for its managed objects and manipulate them freely. 

On a component-based project where the development Generally loop iterations are prime candidates for significant 

should reuse extensively, the name of a component and its 65 performance improvements. If the iterations are distributed 

methods are perhaps the strongest medium of communica- over every object that interacts with object A, little perfor- 

tion between the original developer and a developer inter- mance improvement of component A may be gained without 
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high impact. By restricting interfaces such that only object dead. Today, one is wiser about including batch in the scope 
A may iterate over its own managed objects, the iteration of both architecture and application efforts. One also finds 
code can be tuned with little impact outside object A. that many of the principles and concepts that apphed to 

Perfonnance improvements can always be identified. The batch twenty years ago also apply today, 
difficulty is in the cost of actually implementing them. The 5 1° general, batch still has the following fundamental 
strong pursuit of encapsulation allows bottlenecks to be characteristics: 

identified more easily (i.e. in one place), and tuned with Scheduling — Services are required to manage the flow of 
minimal impact. processing within and between batch jobs, the interde- 

Leverage Functional and Technical Tuning pendencies of applications and resources as well as to 

Though tuning of a component-based application can be lo provide integration with checkpointing facih'ties. 
deferred until late in development, eventually it must be Restart/Recovery — ^Batch jobs must be designed with 
done. At this point it is important to realize the difference restartability in mind. This implies the need for a batch 

between functional tuning and technical tuning. restart/recovery architecture used to automatically 

Functional tuning involves a combination of cognitive recover and re-start batch programs if they should fail 

and measured tuning. It consists of looking at the functional 15 during execution. 

design of a component and determining which portions of Controls— Run-to-run and integrity controls arc still 
processing can be deferred, cached, etc. It demands a required to ensure that all data is processed completely, 

developer who is fimctionaUy knowledgeable about the Reporting— Services are required to handle configurable 
desured behavior, whether it be architecture or application. It report creation, distribution, printing and archiving, 

often results m reorganizing or redesigning portions of code. 20 These services are typicaUy not provided through com- 
The performance gains realized during functional tuning are ponent technologies. They can be provided by third-party 
generaUy the most significant gains. products or custom implementations. 

Techmcal tuning is a lower-level approach to tuning. How is batch different in a component-based system? 
developmg more efficient techniques to achieve the same A system's batch architecture can be easily overlooked 
functionality. Technical tuning demands a developer who, 25 since it is not a part of the system that is visible to end-users 
though not necessarily intimate with the functional Regardless, it is critical to design components with both 
requirements, has a strong familiarity with tricks and tech- on-line and batch requirements in mind. Combining both 
mques of the development platform. It can involve better use sets of requirements is necessary to ensure that your com- 
of memory, language idioms, base class modifications, etc. ponents can be used in both environments. This wiU allow 
Technical tumng should require Kttle or no changes to 30 the batch programs to act as just another cfient to your 
application code, and narrow changes to architecture. components. 

Opportunities for performance tuning are found both in In addition, since many on-line systems are expected to be 

bottienecks and in distributed inefficiencies. There are gen- available on a 24x7 basis, there may be a limited window 
erally many tools available in detecting botUenecks. Dis- available for exchisive batch processing. This requirement 
tributed mefificiencies are usually more difficult to identify 35 can have a tremendous impact on your batch architecture. In 
with tools. Whether performance optimizations are realized these environments, it is necessary to design batch programs 
through cognitive analysis, or tool-assisted profiling, it is that make efficient use of resources and have a low impact 
important to measure the gains against a baseline perfor- on on-line users. 

manoe level. A component-based batch architecture must support batch 

Few performance improvements are gained by eliminat- 40 programs that read transactions that are really messages 
mg completely useless code. Gains are usually achieved by These message transactions are read either from a flat file or 
trading speed for size, or chronologicaUy reorganizing pro- from a database. The program must then locate the compo- 
cessing. Improvements in one area may weigh in a different nent for>^ch the message is intended and pass the message 
area. For example, runtime processing is often sped up by to that component for processing. In many cases, these will 
mcreasmg miUalizaUon time. When making such changes, 45 be the same components that process messages fiom on-line 
measunng the affected runtime processing is insufficient. It (GtTI) applications. The fimction of the batch "program" in 
is necessary to measure also the areas impacted to detennine this environment is fairly limited. It reads the input 
that ^e optunization does not push another area into unac- messages, controls the packaging of database units of work, 
ceptable response. and sends requests to the business component that performs 

Summary 50 the actual business logic associated with the messages. 

Performance is an acknowledged risk in developing com- Batch architectures usually "commit" on intervals that are 
plex systems with today's maturmg component technolo- designed to optimize database resources. Thus, it is impor- 
gies. To reduce risk and uncertainty, it may be necessary to tant to design components that can participate in a logical 
develop prototypes that validate the architecture approach. unit of work that is controUed outside of the components 
When components are built using rich object-oriented 55 How do the patterns in this section help-? 
frameworks. It is possible to tune a component-based system The patterns described in this section represent some 

more effectively and later in development, than its structured initial attempts to capture basic concepts that are useful in 
counterpart. Other more traditional approaches to the design of a component-based batch architecture. They 
components, may requu^e tunmg throughout the develop- are by no means exhaustive but represent buHding blocks in 
ment cycle. 60 a complete solution. 

Base Services (1020) The Batch Job pattern describes a method -of stmcturing 

Batch processmg is used to perform large scale repetitive batch components so diat common architectural services are 
processing where no user involvement is required. Batch implemented uniformly across all of these components. In a 
support IS an often overlooked area m architecture and way, this is the component-based analog to the concept of 
component design. When first chenl/server and then com- 65 sheU designs and skeleton prc^ams which have been a 
ponent lechiiology hit the scene, the emphasis on GUI and recurring feature of robust batch architectures for many 
communications was so strong that many thought of batch as years. 
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The Batch Unit of Work (BUW) pattern, on the other 
hand, represents a method of structuring the work to be 
processed by the batch components so that it too can be 
treated uniformly by all components. An abstraction such as 
this forms the basis for distributing batch workloads in a 
nimiber of useful ways. It also enhances the capability of the 
architecture to support evolutionary change. 

The Processing Pipeline pattern describes a way of struc- 
turing batch activities so that they can be easily reconfigured 
as processing requirements change. This pattern directly 
addresses the issues of scalability and reuse in a component- 
based batch system. 

The Abstraction Factory pattern has a much broader 
applicability than just batch systems. It represents a way to 
encapsulate diversity such that only those parts of the system 
that need to understand the difference between two objects 
have to deal with those differences. To use a typical batch 
example, a file is a file is a file. Only those components that 
require knowledge of the contents of a file should need to 
deal with those contents in other than a very generic way. 

What are some other considerations in developing a 
component-based batch architecture? 

Because batch processing executes on a server and 
requires limited user interaction, many of the services used 
for on-line architectures are not needed. For example, the 
services used for distributing components — naming, distrib- 
uted events, bridging, trader, etc — are not needed for a batch 
architecture. In fact, the interfaces that encapsulate compo- 
nents and provide location transparency can add significant 
overhead to a batch architecture. To avoid the expense of 
unneeded senrices, the component stubs can be wrapped 
with a layer of indirection that short-circuits the normal 
distribution mechanisms. This will provide performance that 
will approximate local function calls. 

Typically, business objects have to be instantiated from a 
relational database (RDBMS) before the batch application 
can make use of them. This extra overhead is a very real 
concern. It is an unfortunate fact that in many ways the more 
"object-oriented" your design is, the worse it fits into the 
relational paradigm of rows and tables. For one thing, these 
designs tend to have lots of objects with embedded instances 
or references to other objects. And the primary reason that 
such designs have RDBMS performance problems is that in 
the database, resolving such an object relationship requires 
joins or recursive queries. When mapping from your object 
model to the RDBMS, there is a tendency to "normalize" 
your object over many tables, and the performance can 
easily plummet. 

Is efficient component-based batch hopeless? No. But if 
you have stringent batch performance requirements, you 
may need some specialized design. There are several tech- 
niques you can use to improve your batch speed. 

Reduce (eliminate, if you can) batdi. This may sound 
simple and stupid, but is often overlooked and is by far 
the cheapest way to improve your batch yield. Lots of 55 
reports can be obtained on-line, lots of them are not 
useful or used, "trigger transactions" can simply 
become spawned sub-processes that run in the 
background, same for printing bills, the only thing that 
must be done in batch is a database reconciliation, 60 
which requires a time window with no other activity. If 
you can engage in discussions for eliminating batch, by 
all means do. 

Pool (recycle) objects. Each time you dispose of an 
object, instead of destroying it put it in a pool of 65 
recyclable objects; and every time you create a new 
object, look in the pool to see if there is one that can be 
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recycled. Keep separate pools for each class of objects. 
Allocating objects is a lot more expensive than one 
tends to think, and recycling can improve your batch 
performance dramatically without affecting your 
design. 

Cache and sort. This technique is well known to "tradi- 
tional" batch designers, but it is so obvious that they 
don't even think of it. However, it has a correspondent 
object implementation. Keep a anall cache of objects 
you have just read from the database. Most of the times, 
one instance of each is plenty. Whenever you need to 
access an object on the database, look to see if it is 
already in the cache. If not, read it and put it in the 
cache too. Encapsulate all this logic in a technical 
"Table" object — not in the business objects. At the 
same time, organize the processing of your data in a 
sequence that maximizes cache hits. Again, this tech- 
nique does not affect your "business objects" design. 
The processing cost of this technique is so low that you 
can keep it enabled also for on-line, thus simplifying 
your technology architecture. 
For some applications, an LRU caching policy might not 
be the right choice; a more complicated scheme with mul- 
tiple cache levels might be necessary. For this reason it 
would be best to make the caching policy itself be an object 
(consider the Strategy pattern for making an object from an 
algorithm) so you can change the policy on demand. 
Cache operations and accesses. One of the reasons 
component-based batch performs so poorly is due to 
the fact that, in order to maximize modularity and 
preserve encapsulation, a lot of operations are per- 
formed redundantly. For instance if a balance is imple- 
mented as a calculation, and if it is needed by six 
different objects it is recomputed six times. These 
situations are very easy to identify with a performance 
monitor that tells you where the program spends most 
of its time; it is not uncommon to find that most of the 
time is actually spent in very few methods. For these 
methods (and only for them!) cache the result in an 
instance variable. Every time the method is invoked, 
check if the instance variable contains an answer: if not, 
compute it and store it there; if yes, just return it. Of 
course, each operation on the object that invalidates the 
result of the computation must invalidate the cache too! 
This technique has a very small impact on your object 
design and typicafiy leaves the interface unchanged. 
Cache objects. Typically, this would involve leaving 
recently referenced objects instantiated in memory for 
some length of time after their last use. Then, if the 
object is accessed again, you check the memory- 
resident cache before re-loading the object from the 
DBMS. Usually you would construct this cache as a 
hash table keyed by object ID, and use a LRU pohcy to 
keep the cache size manageable. Expect degraded per- 
formance if you do anything to destroy the utility of the 
cache. For some appfications, LRU might not be the 
right choice; a more complicated scheme with multiple 
cache levels might be necessary. For this reason it 
would be best to make the caching poficy itseff be an 
object (consider the Strategy pattern for making an 
object from an algorithm) so you can change the policy 
on demand. 

Make use of "lazy" or "deferred" loading. That is, don't 
do a "deep" instantiation untQ you know you're going 
to use the associated parts of the object. Instead, load 
selected sub-objects only when first referenced This 
can save on memory overhead as well as DBMS access. 
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In some cases you can use a hybrid strategy: do a language. As an option, the located concrete object may also 

"shallow" instantiation by default, but provide the be inserted into the abstract object. With this option the 

cUent program with a way to build the complete object abstract object may operate as a handle 

on demand to provide more deterministic performance. |. • H#*«rahi** fn «^ar!»**. w * u * *. / 

you really do tend to use most parts of the object durme 1**1. r , y^'^J ^" 

. ^« u>^i- uj^ yuj«,t uuimg ^ exploit the power of polymorphism, using an abstract 

high-volume processmg, loading it in piecemeal can , u - i. • I <i^au»udei 
actuaUy worsen the performance, becauL of the over- T^f^'^tLT^^. mplements that mter- 
head of maintaining^e load state and because of the these con«^te mstancesand 
no\>rc ♦ _** • . i_ * mampiuate tnem within a framework while preservme the 
smaller DBMS transactions sizes. These t«;hmques ,o framework's independence? ^ ^ 
nave a very small impact on your object model. - 1 - 
De-nonnalize your database when> possible. Typically J^, !^^Z7fT^T.T' P^'/'^^,^^'^.'^''^ ^ 
when one does object-to-relational Icings, o^^ten<b ^ ' J-'^''^ ?f types of mformatK^n with a cone- 
to make every Jque object type a seJLfuble. ITiis IC^^^^n '^^"^^^T"''^^^''u''"T'^ 
is best fiom a design pe^pecth^. But in cases where 15 u^Z T^Z,?^ °f mtinst^k evolves 
1 u /. jT ^ „^ ■ „ ■ .■ takmg an mioimation source and creatine an aoDioDriate 
you know you have a fixed set of "pnvat6"associatons intoJfoi „™»c„ . »• <• •. "-"^"imB tu appiupndic 

■ , , mtemal representation for it 

(meaning physical aggregation with no possibility of -n. , ■ t u . - 

shared references), then fold that subK)biect data into , ^^'^ approach to this problem takes the form of a 

the enclosing object's RDBMS table. It's not pretty,but switeh/case statement^ where each case deals with one 

itcansavelotsofextraIoadingtime.Also,lookatways 20 >nfonnabon types. TTie swtch/case approach leads to 

to do aggregate loads based on some unique object ID. components that are vey difScult to maintain, extend. 

For example, if you have collection-valued sub- Tl"^ ^ ^V"^ \ " procedural programming 

components, insert the object ID ofthe enclosing object apP^ach abo makes it extremely difBcult to 

in the sub-object tables and do aggregate loads in code, P.T """"P dependencies so that the details depend on 

rather than doing a "point-of-use" instantiation for each 25 ^amework and not vice-versa. 

one separately. Of course, these optimizations can have ^'"^ ^ alternative approach must be used 

a more substantial impart on your object model. * ftamewoik to handle multq>le informa- 

Considermaking''Ught''versionsofsonieofyourobiects. t»°n types in a way which encourages good style. 

That is, for performance critical atuations, create alter- ^<^»"^' extensibihty, and framework independence, 

nate implementations of your business objects that 30 . one transforms the various types of raw data 

don't have all the baggage ofthe fiist-class objects. Yes, * corresponding variety of concrete object types, all of 

this can be ugly and more difficult to maintain. But for T^'*^*" * common abstract interface. This transforma- 

many batch processing appUcations you might find that ^ ^ encapsulated within an Abstraction Factory, 

you can drop a lot of the (persistence-related) com- primary interface to the Abstraction Factory is: 
plexity of an object without affecting the batch pro- 35 "abstractType pioduceForKeyCkey)" 

cessing at all. Then create fast hand-tuned routines to where "abstractType" is the type of the common abstract 

mstanuate the hght objects from the database. interface, and key is a piece of information which identifies 

As can be seen, there are a lot of opportunities for the appropriate concrete type. (This could be the same piece 

miprovement m component-based batch performance. ofinformatfon used in the switch/case statement; there could 
However, in order to manage nsk early, remember that the 40 be a variety of ways to get it). When this method is invoked, 

areas m which you will have trouble are those in which batch the Abstraction Factory consults its internal mapping and 

excels (predicUbility. repeUtivene^) and component-based creates an "empty" object of the proper concrete class The 

design trades off perfonnanoe for flexibdity and encapsuk- factory then casts the concrete object into the abstraction and 

tion. Message overhead and amilar language related issues returns it to the method's client. This client (a frameworic 

are unhkely to be critical Obviously, before doing any of 45 most likely) wiU then instruct the abstraction to initialize 

these things you should do some serious benchmarking to itseff from the incoming date stream, 

see where you're coming up short on performance. Often the a. »_j t.u- u . . u j, 

overhead comes from surprising pkces. Don't twist your , L K^^t '^u'^ 

objectmodelaUoutof sha^e wiSoutfirsthavingsomei^lid " ""^^ then manipulate 

performance measurements. 50 ^ « 

Abstraction Factory Benefits 

FIG. 54 illustrates a flowchart for a method 5400 for Software Quality. Exploiting this pattern can aUow us to 
providing an abstraction factory pattern. Data is received avoid one of the major pitfalls of procedural 
and transformed into a plurality of concrete objects in programming, the switch/case statement. Done prop- 
operations 5402 and 5404. Each of the concrete objects is 55 erly you get better modularity, testability, maintenance 
associated with an abstract interface in operation 5406. A extensibility. 

map of the association between the concrete objects and the Frameworks. The layer of abstraction introduced allows 

abstract interface is created in operation 5408. In operation us to build frameworks which follow the open/closed 

5410, when request is received which includes an identifier principle, that is to say, they are open to extension by 

for one of the concrete objects and an identifier for the 60 the addition of new concrete types, but arc closed to the 

abstract mterface. The map is consulted to locate the con- necessity of risky and costly modification. 

Crete object that has been identified in operation 5412. An Implementations of this pattern wiU vary widely depend- 

abstract object is then created that corresponds to the located ing on the selection of language. For example, in C-h- a 

concrete object in operation 5414. generic factory, based on templates can be constructed, and 

nie identifiers may be mciuded with a single request. In 65 key-concrete type pairs can be registered to the appropriate 

another aspect of the present invention, the abstraction instantiation of the class. This might require manual coding 

factory pattern may be written in a C++ programming in other languages. The key interfaces, however are: 



us 6,636,242 B2 
193 194 

Abstraction Factory: Therefore, represent each type of batch job in the system 

AbstractlVpe prDduceForKey(key) as its own class. An abstract class (BatchJob) will exist &om 

Abstract Type: which all specific types of batch jobs will derive from. The 

init(some data stream) abstract BatchJob contains data that all batch jobs require: 
The Abstraction Factory can be fiilly coded in C++. It is 5 name, current status (pending, started, finished, deleted), 
very re-usable as it stands. In addition, it has been messages encountered during its run, various times 

extended to perform "Java Loader-like" dynamic link- (submission, start, completion), and a priority, for example, 

ing if the proper code carmot be found already within should provide some default behaviors including 

the factory. running the job and logic to execute before and after the run. 

Factory, the well know pattern from Gamma, et. al lo . illustrates a class diagram of the batch job 

BUW, in which the objects created by the factory can be hierarchy. 

dealt with generically in terms, of independence. Various system batch job classes can subclass from the 

scalability, parallel processing, etc. Component Solu- abstract BatchJob 5600 and add their own required attributes 

tions Handbook. behavior. A "Bill Customer** batch job may need the 

Batch Job 15 identifier of the customer to bill and the time period for 

FIG. 55 illustrates a flowchart for a method 5500 for ^^^^ ^ should be attributes added to the 

representing a plurality of batch jobs of a system each with concrete subclass: BaiCustomerBatchJob 5602. In addition, 

a unique class. In operations 5502 and 5504, an abstract concrete class needs to supply the actual logic that the 

class of abstract data required by a plurality of batch jobs is performs (along with any pre- and post-run logic), 

provided and a plurality of batch job sub-classes are defined. 20 ^^^y* concrete batch job class should provide some 

Each batch job sub-class includes batch specific data, and ^ start-up all of the pending jobs in its class. A class 

logic for processing the abstract data and the batch specific method is implemented on the abstract class to start all 

data upon the execution thereof. Each of the batch job pending jobs. This method can be overridden by any oon- 

sub-classes is represented with an object in operation 5506. extension of the BatchJob superclass. 

In operations 5508 and 5510, one of the objects is identified 25 implementing batch job instance as any other type of 

and the logic of the batch job sub-classes associated with the object, the batch architecture may then take advantage of the 

identified object is thereby executed. system services available to all other business objects 

In one aspect, the daU may inchide a name, a current ^ sys*®™ (persistence, transaction management, error 

status, messages encountered during a run, various times, handhng, logging, security, etc.). 

and a priority. In another aspect, the abstract class may 30 ^^^^ 

include default logic for running a batch job. Natural Representation. Each type of batch job is repre- 

In an additional aspect, the abstract data and the batch sented by an object. This allows it to interact with the 

specific data may be stored separately. In a fourth aspect, the °f the system in a natural way. 

logic of the batch job sub-classes may be executed by a Extensibility. By providing an abstract superclass, adding 

scheduler. 35 new types of batch jobs only require adding a new 

A set of logical operations may need to be initiated concrete class to the system, 

through some '1)atch** scheduling means. This requires a set Architectural Separation. Batch Jobs that are not imple- 

of common services such as activation, logging, and error mented "inside** the object-oriented environment can 

handling that will have to be applied across all jobs. How still be tracked by the batch job objects. The rest of the 

can these common services be distributed to all types of 40 system is unaware of the batch job objects, 

batch jobs? FIG. 57 illustrates an object interaction graph of a pos- 

Most business systems today include some sort of batch sible implementation of the example of FIG. 56. FIG. 57 
processing. Batch processing is the execution of a series of illustrates a batch scheduler 5700 which interfaces a 
instructions that do not require any interaction with a user to BillCustomer Class component 5702 whidi in turn inter- 
complete. Batch jobs are usually stored up during the day 45 faces a BillCustomer BatchJob component 5704. 
and executed during evening hours when the system load is ISO New England energy eXchange. A net-centric inter- 
typically lower. net system build for managing functions associated 

Once a batch job begins, it continues until it is complete with a competitive energy market. The energy 

or it encounters an error. eXchange is implemented in Java across client and 

An architecture that supports batch jobs usually has 50 server components and using CORBA as a communi- 

certain characteristics. It must be able to support checkpoints cations architecture. 

and rollback, restart and recovery, error handling, logging. Batch processes are often highly resource intensive. In 
scheduling, and resource locking. many cases the required throughput demands the use of 
Most systems, including those that are component-based, multiple processors, possibly distributed, to provide seal- 
require this sort of architecture. A diflSculty arises when 55 ability. How, then, should one structure one*s batch work- 
considering component-based systems though. In a load to facilitate a robust and scaleable system? 
component-based system, the application architecture is BUW 

usually very separated fi^om the business application classes. One of the primary techniques used to achieve scaleable 

In many cases, the business classes and components are built batch applications is parallel processing. There are many 

without regard to the surrounding architecture. eo different types of parallel processing, but the simplest and 

It is expected that the business components will execute easiest to exploit occurs when the problem domain contains 

in some environmental container that will provide many of many independent work items. In this case, the work can 

the architectural services (like batch sendees). simply be divided among the available processors, providing 

Some natural representation of the batch architecture must nearly linear scaling, 

be developed and transparently integrate with the existing 65 Happily, this is exactly the situation encountered in many 

business components and still support all of the architectural batch systems. However, also given the nature of batch 

requirements. processing, the variety among the various work items will 
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likely be large. This of oouise leads to the need to treat some The connectors may peiform the steps of acting as a choke 

items differently than others, and there goes the nice clean point for data to be pulled from a filter, connecting serial 

scaling model. filters defined as independent processes, and/or multiplexing 

\^th this in mind, some alternative approach must be used to demultiplexing fi-om several filters of the same type 

which will allow a cleanly scaleable framework to handle 5 running in parallel. As another option, one of the filters may 

multiple heterogeneous work types. be positioned between the input and output filters of the 

Hierefore, one creates an abstraction which represents a process for translating an output of the input filter into an 

batdi unit of work. Now the design tension comes in. input type of the output filter. 

Clearly one common abstraction is easy to parallelize, but How do I define a disciplined strategy to structure the 
not very interesting to manipulate due to its very generic components performing processing steps within a batch 
nature (at least if you're interested in type safety). This system so that the system is cleanly partitioned while 
quickly leads us to design a shallow tree of more interesting maintaining performance and scalability goals? 
abstractions, and again one's clean scaling model seems Often batch processing systems perform a series of pro- 
threatened, cessing or transformation steps on input objects that are 
The key is to treat the work units as top level abstractions streamed into the system. Implementing such a system as a 
while they are being routed among processing nodes and to single component is not feasible for several reasons: por- 
treat them as more interesting derived abstractions when tions of the component must be developed by several 
internal to a node. Treating them as topmost abstractions developers, requirements are likely to change and it is 
between nodes provides a good lever for robust processing, difficult to cleanly partition the modules resulting in a highly 
as typical actions like lO/persistence, recovery, auditing, etc. coupled system. 

can often be treated uniformly for all types. 20 Compounding the diflSculty in implementing the system is 

Treating work units as derived abstractions while internal the fact that most batch systems must satisfy the following 

to a node is achieved by actually creating the abstractions challenging requirements: 

within the node. See the Abstraction Factory pattern for Must be able to satisfy extremely stringent performance 

details on one way to achieve this. criteria. 

So are we safely scaleable now? Not necessarily. There is 25 The system must scale to meet client's volume, 

still the danger that a given processing node will be pre- The system must be flexible enough to be adapted to 

sented with a unit of work it cannot deal with. Kind of like various contexts. 

asking a parking meter for a hot pastrami. This situation can These requirements are difficult to meet for any system, 

be avoided with proper workflow, or with sufficient and batch systems' stringent demands often lead developers 
structure, a dynamic library loading version of the Abstrac- 30 to think they caimot use component technology. Building a 

tion Factory could, in effect, tell the parking meter how to fix procedural batch system to satisfy the requirements listed 

sandwiches. This of course, has the effect of a one time above may result in a complicated set of modules that are 

performance hit as the processing node is instrumented with difficult to maintain as the system is scaled. By utilizing 

new capabilities. component technology's ability to manage complexity 

Implementations of this pattern will vary widely depend- 35 through encapsulation, a component-based batch system can 

ing on the selection of languages and technical architectures. more easily be defined with clean partitioning than when 

The key is that the all work units in the system are derived using a procedural paradigm. Defined with foresight, this 

from a single abstraction. This abstraction contains key partitioning enables the system to scale to meet difficult 

interfaces that are appropriate at the workflow level. Derived performance requirements. 

abstractions add interfaces as needed functionally. 40 Therefore, encapsulate each processing step within a filter 

Abstraction Factory, in which concrete objects are created component. A filter consumes and delivers its results 

by the factory and returned to the Factory's client as an incrementally, rather than consuming all of its input before 

abstraction. CSH. producing output. The incremental nature of filters aUows 

Processing Pipeline them to significantly reduce latency and enables true parallel 

FIG. 59 fllustrates a flowchart for a method 5900 for 45 processing, 

structuring batch activities for simplified reconfiguration. In A supplier provides the input to each filter, and the filter's 

operation 5902, a series of processing steps are prepared for output flows to a consumer. Suppliers and consumers may be 

performing on input objects being streamed into a batch objects that read files, databases or queues, other filters or 

processing system. Each of the processing steps is encap- any type of object supplying or accepting data. In order to 

sulated within a filter in operation 5904. The input objects 50 produce a flexibly arranged system, connect the initial 

are received and processed in the filters in operation 5906. s^Tplier, the filters and the final consumer with pipe com- 

In operation 5908, results are dehvered from the filters ponents that are responsible for implementing the data flow 

incrementally during the processing of the input objects for between adjacent filters. 

reducing latency and enabling parallel processing. In opera- As a result of filter processing's iiK:remental nature, one 
tion 5910, coimectors are utflized for connecting at least two 55 or more filters, tied together with pipes, define a process's 
filters each having a processing step for creating a process. Logical Unit of Work (LUW); i.e., the filters defining the 
One of the filters is an input filter of the process and another steps of the process are sandwiched by the beginning and 
of the filters is an output filter of the process. Connectors are ending of the transaction. Expanding this model, eadi sub- 
also used in operation 5912 for connecting input and output system representing the LUW can be modeled as a filter with 
filters of different processes for forming a scalable system. 60 input and output that encompasses the internal filters. These 
There may be several instances of a particular type of filters are then tied together through the use of pipes to 
filter running in parallel. A portion of the filters may be represent the system. In this manner, the Processing Pipeline 
active and a portion of the filters may be passive. In such a pattern offers a consistent way to view the system that scales 
situation, the active filters may puU input data and data may to whatever size and degree of complexity the system grows, 
be pushed into the passive filters. Additionally, the input 65 Benefits 

filter of the process may be an active filter and the remaining Scalability. Each filter performs its data processing and 

fillers of the process may be passive filters. transformation independently of other filters. By lever- 
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aging off some pipe forms' multiplexiDg/ Collaborations 

demultiplexing techniques, there may be several Abstraction Factory. Often filters will need to produce 

instances of a particular type of filter running in par- new data objects fiom input but are only aware of the data's 

abstract interfaces. As a result of this generality, the filters 

Partitiomng. As a result of encapsulating each processing 5 will need to utilize an abstraction factory to produce con- 
step withm a filter component it becomes easier to ciete objects without knowing their concrete class types, 
inanage the balance between coupling and cohesion Business Logic Service Patterns (1024) 
since there are disciplined and weU^efined interfaces ^s is stated in the Component Technology Architecture 
surrounding the components Framework, "Business components are the' core of any 

HexiT)ihty.Smce filters make htUe assumptions about A application, they represent concepts within the businei 

Tr ™l fit""* '^"'^ ^ ^ "^"^^f,"^ r encapsulate the irrformation and behavior 

ner; several filters can be combined together and «„™v..«^ „/*u *u * ^ ^ ^ • 

wrapped by a larger-grained filter; filte^rs can be ^^f^f ^^h those concepts. Examples of b^^ 

dynamically assembled at rmi-time depending on some h".^ ^Tv'' ^'^l'''' Inventory, 

context, etc. Pncmg, Credit Check, Bilhng, and Fraud Analysis." These 

pilleis 15 are the components that in many cases have been the most 

At a high level, there are two types of filter components: elusive for reuse but hold the highest promise for atUcking 

active filters and passive filters. An active filter pulls input development. In this area there are at least three 

data fi-om its suppliers, processes the data and outputs the targeted categories of business components. Common Busi- 

result to its associated consumer. In contrast, input data is °ess Components, Common Business Services and Com- 

pushed into a passive filter, which then performs its pro- Business Facilities. 

cessing step and outputs to its consumer. Common Business Components are those components 

Typically a system is defined by an active filter at the ^ preceding list that encapsulate key business con- 
beginning of the Processing Pipeline, that pulls input data cepts. At one level these components represent cross appli- 
from the data source and initiates further processing by cation components that are common to a plethora of appli- 
pushing the data to a chain of passive filters situated down ^ cations. These include concepts like Customer, Company, 
the pipeline. Often the active filters are only responsible for Account, Shipment, etc. These common components nor- 
pulling data into the system, while the core business fimc- malize how basic behavior surrounding common business 
tionality is performed by passive filters. concepts can be normalized. Common Business Compo- 

Because active and passive filters demonstrate different °ents are very concerned about the validity of the relation- 
levels of pro-activity, it is useful to further break down the ^ f ^^ey have with other components and ensuring that the 
type of consumers and suppliers into four general types: information relationships are maintained correctly, 
push suppliers, pull suppliers, push consumers and pull Common Business Services deal with the higher level 
suppliers. These four simple abstract interfaces help segre- services that abstract out the "Business Unit of Work" or 
gate the fundamental, yet disparate, behaviors. Active filters transactional aspects of business processing. Having 
inherit both fi-om PuUConsumer and PushSupplier. Active components that capture key processing concepts normal- 
filters' sources inherit from PuUSupplier, and their destina- ^es the processes for handling business events. These are 
tions inherit from PushConsumer. Passive fillers inherit from services like credit checks, ordering, servicing problems, 
PuUConsumer and PushSupplier. Passive filters' sources shipping, product selection, etc. They tend to capture busi- 
inherit from PushSuppher, and their destinations inherit ness practices and when reused enable a company to increas- 
from PushConsumer. 40 ingly leverage the value of those practices. 
Pipes Common Business Facilities are those services that deal 

While filters define the basic processing steps, pipes with areas of more engineering component type reuse. These 

define how to flexibly configure the system. Pipes can-be include base common facilities like reason codes^ currency 

used to connect filters in a wide range of configurations: management, telephone and address manipulation and vah- 

Acting as a choke point for data to be pulled from an common business types, 

active filter ^ ^e patterns in this section help? 

Connecting serial filters defined as independent processes . J}"? patterns described in this section represent some 

Multiplexing to/demultiplexing from several filters of the T ""'"^Tr ""^^T ^'^'^ ^"^'^ '^^^ "^w^ ^ 

same type nmning in parallel ^T'"^" Facihties. Tliey are by no 

Pipes may use buffering, multiplexing and '° "je^ e>±ausUve but represent bmld^^ 

de-multiplexing techniques in order to transfer data tStween P^^^'^^Tn * ^^u"^"" tremendous value m solving 

filters. Some examples of usefid pipe implementations ^^J^y ^^affeng^ which appear onevery engagement, 

include- *- r i- The Constant Class pattern describes a facility for ensur- 

r^r.' 1 J n: n u *t- . « correct data at the attribute level. 

Channeled Pipes. Perhaps the most generaUy useful form ^^^^^ ^^^^ ^^^^ ^ j^^^. 

of apipe isbasedontheCOMAEvent ttannelobj^^ architectural mechanisms within businL objects 

which can connect any number of Push/PuU Supphers Attribute Dictionary 

to any number of Pu:^i/Pull Consumers. eo n * ; a u r *u j *.o«« 

XM J J t^* ^ ^ illustrates a flowchart for a method 5800 for 

MulUthreaded ftpes T^se pipes route daU to one of controllingaccesstodataof a business object via an attribute 

several filter threads TTie data can then be joined back ^ dictionary. A plurality of attribute values for a business 

to the pnmary thread on the other end of the filter with object are stored in an attribute dictionary in operation 5802. 

a demulUplexmg pipe. ^ phirality of attribute names are provided in the attribute 

Database Queue Pipes. These pipes wrap around a daU- dictionary for the stored attribute values in operation 5804. 

base queue to enable seamless data transfer between Next, in operation 5806, it is verified that a current user is 

processes. 55 authorized to either set or get one of the attribute values 

The various command shells enable filter programs to be upon a request which includes the attribute name that 

tied together into a Processing Pipeline. corresponds to the attribute value. The attribute value in the 
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attribute dictionary is obtained or updated if the verification 
is successful and an indicator is broadcast upon the attribute 
value being updated in operations 5S0S and 5810. 

In one embodiment, a list of the attribute names may be 
outputted in response to a request. Additionally, the list may 
also include ooly the attribute names of a portion of the 
attribute values of the business object that are present. 

In one aspect, the attribute values may be obtained for 
auditing or rollback purposes. In another aspect of the 
present invention, a dirty flag may be set upon the attribute 
value being updated. 

Typically, lousiness objects include "getter" and "setter" 
methods to access their data. How can I support value-added 
processing, such as logging events for changes, without 
impacting application code? 

Typic<3ly, business objects store attributes in instance 
variables. The application code for a typical setter for an 
attribute is depicted as: 



public void setBalaiice(Float newBalance) { 
myBalance - newBalanoe; 
return; 

} 

Initially, this is straightforward. However, after aU of the 
attribute setters and getters have been coded, the need may 
arise for an event to be broadcast each time an attribute is 
updated. The code for a simple setter would need to change 
to become: 



public void setBalance^oat newBalance) { 
myBalance = newBalance; 
thiB.notifyCaianged("Balance'*); 
return; 

} 



10 



15 



200 



changes impact application developers during coding and 
maintenance. Moreover, they also complicate business logic 
with technical details. 

Therefore, the application architecture should control 
access to a business object's data. This will separate out 
reusable, technical, architecture details. Business objects 
should use an Attribute Dictionary to provide an architec- 
tural hook for attribute getters and setters. Moreover, this 
framework should handle all architectural processing related 
to the update and access of data, transparently to application 
logic. 

Rather than using instance variables, the Attribute Dic- 
tionary holds all attribute values for the c^ject. This dictio- 
nary is a collection, keyed by attribute names. Then the 
architecture can provide generic architecture methods to get 
and set attributes in the dictionary. 

Business objects could each delegate directly to the 
Attribute Dictionary within the attribute getter and setter. 
However, rather than having each business object talk 
directly to the Attribute Dictionary, simple helper methods 
can be created in a superclass for business objects. This 
simplifies the interface for application developers, who do 
not need to know about the Attribute Dictionary. This also 
allows for business object specific logic to also be added 
prior to and after the dispatch to the Attribute Dictionary. 

The code for a simple setter now would look hke: 
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dass Account extends BusinessObject { 
public void setBalance( Float newBalance ) { 
// set my balance with the new value 
// passed in. The architecture will handle 
// any technical details related to 
// setting the data. 

this.setAttrflmte( "Balance'*, newBalance^, 

} 



Now each attribute setter must contain the call to the 
'notifychanged' architecture method. This implementation 
forces architecture mechanisms to be intrusive to application 
code. Moreover, addition or extension of architecture pro- 
cessing should not impact business logic. One new line of 
code alone may not seem like a large burden on application 
developers. However, many other architecture requirements 
might later affect each setter or getter. 

As another example, before updating an attribute, a check 
may be required to determine if the current user has security 
rights to update attributes. Also, after successftil update, a 
dirty flag may be set, or an audit log may be performed. TTie 
code for each setter now looks as follows: 



public void setBalance( Float newBalance ) { 
// keep track of my original balance, 
// for post-change processing, then do 
// some pre-processing to check 
// that the user has access rights 
Float oldBalanoe - myBalance; 
this.asseitQuiSetAttiibute( "Balance" ); 
// finally update the balance, then 
// broadcast, set the Diity Flag, 
// and log 

myBalance » newBalance; 
this.notifyCbanged( "Balance" ); 
this.makeDirty( ); 

this.logChang^( "Balance", oldBalance ); 

} 



Thus, each added architecture framework for gets and sets 
must be manually added to all getters and setters. Such 



The architecture superclass will then perform the follow- 
ing: 

40 get the original value, perhaps for auditing or rollback 
purposes 

check if the user has security access to set the attribute 
update the attribute on the Attribute Dictionary 
if successful, broadcast and log the change 
45 The Attribute Dictionary would then contain the code to: 
update the value for the given attribute name 
set the dirty flag 

This illustrates that both the superclass facade and the 
Attribute Dictionary can have different processing. In 
50 general, one generic location for getting and setting 
attributes supports (but is not limited to): 

logging 

broadcasting 

dirty flag 

security checking 

NULL field value handling 

This logic will be either in the facade methods (for any 
code that is business object specific), or the generic methods 
60 on the dictionary, thereby shielding developers from this 
added complexity. 
Benefits 

Maintainability. Architecture code can be added and 
changed in one place for all objects, without change to 
65 the application code. 

Flexibility. The implementation of the storage mechanism 
can be changed as needed to improve perfonnance. 



us 6,636^42 B2 
201 202 

Readability. The methods used in application code to These overloaded methods create a generic interface to 

retrieve and update fields on the object are generic. the AltributeDictionary for attribute setters. They ensure 

These methods do not have excess architecture code to type checking, such that no attributes will be set to a value 

detract from the purpose of the method. other than those for which an overloaded method exists. 

Object Model 5 public String[ ] attributeNames( ); 

HG. 60 iUustrato the manner in which the AttributcDic- jhe method attributeNames( ) returns a collection of the 

tonaryChent 6000 is the facade which delegates to the those attributes that have been populated (or 

AttnbuteDiction^ For example busmen obje^ the dictionary. This might be useful for other 

woidd mherit this beha^^ Atta^uteDictionaryaient 6000 fr^^works, which may want to itelate over all attributes. At 

probably wouldn't be the immediate superclass, but It would ^ i t: • muui^^i 

be somewhere in the hierarchy. In this mamier, stateful any parhcular tmie, a busmess object inay not contam all of 

business objects, like Account or Customer, can easily take f attnbutes (e.g., because of partial retneval from the 

advantage of the Attribute Dictionary. database). So this may be a subset of the full attribute list for 

The attribute Values attribute on the Attribute Dictionary is object, 

shown as an instance of the HashMap class 6004, which Constant Qass 

stores key value paiis. The HashMap Collection is used to ^ illustrates a flowchart for a method 6400 for 

provide access to attribute values based on the attribute managing constants in a computer program. In operation 

name. This is required for a direct lookup of values associ- 6402, a plurality of constant names are provided with each 

ated with attribute names. Such lookup can use string constant name having a corresponding constant value. The 

representation of the attribute names. constant names are grouped into constant classes based on 

Object Interaction Diagrams 20 an entity which the constant values represent in operation 

There are four interactions for this framework: Simple 6404. Access is allowed to the constant vahies in operation 
Attribute Getter, Simple Attribute Setter, Failed Attribute 6406 by receiving a call including the corresponding con- 
Getter, and ReUieval of Attribute Names. FIG. 61 illustrates slant name and corresponding constant class, 
the internal implementation of the dictionary. [n one aspect, the constant values may be changed upon 

FIG. 61 depicts the use ofthecontainsKey() method 6100 25 being accessed. In another aspect, the constant value may 

on the HashMap to ensure that the value will exist before the also include an enumeration. Also, in one embodiment, 

get( ) method is used. This proactive search for the value accessor logic modules may be assigned to a phiraHty of the 

ensures that the nullPomterException is not thrown from the named constants with the accessor logic modules being 

AltributeDictionary. The performance of such methods will executed upon the accessing of the corresponding constant 

be checked during testmg. If such processing is not 30 value via the accessor logic module. Also, the accessor logic 

performant, the code can be altered and the call to modules may be edited per the desires of a user. 

containsKey( ) removed. In that case, the HashMap will Additionally, the constant values may be accessed without 

need to wrap a Ury-catch block around the get( ) method. the accessor logic modules. 

FIG. 62 illustrates a method 6200 that dictates that any yterals are hardncoded constants referenced in multiple 

nuUPomterExcepUon that is thrown would be caught and 35 places. How can source code refer to Uterals in a maintain- 

rethrown as the more user-friendly exception in the attribute able &shion? 

dictionary paUem envronment. FIG. 63 ilhistrates the Get The concept and value of named constants have been 

the Attribute Names method 6300 in the attribute dictionary realized for quite some time. The idea can date back to 

pattern envronment. Assembler language naming memory locations where data 

Public Interface 40 ^as stored. The purpose is to give the ability to refer to fixed 

The following are methods on the AttributeDictionary. values by the name of what they represent rather than by the 

The AttnbuteDictionaryClient exposes similar public meth- quantity they are set to. 

Named constants allow a programmer to "parameterize" 

public Object getAttribute(String attributeName) raises a system. This allows a programmer to change a constant's 

AttributeNotFoundException; 45 value in a single place rather than every place the constant 

The return value of getAttribute( ) is typically a wrapped is used. In addition to the maintenance gain, readability is 

primitive, or Java type, for most attributes. This includes, for also increased. 

example, an account balance (Float) or account number Many languages offer mechanisms to implement named 

(String). The return value of these wrapped primitives must constants. These include PoolDictionaries (Smalltalk), 

be cast, as illustrated in the following example: 50 enums (C and C++) and public static final declarations 

(Java). DifGculties arise during implementation of these 
mechanisms with respect to type constraints^ visibility, and 

class Account eattends BusinessObject { type checlong. . - 

public Float getBalaiicc( ) { Usmg these traditional approaches, results m global 
// get my balance using the st^erclass &cade 55 namespaoe for these literals. This can result in name colli- 
// cast the return value before rcturning it sions. For example, the name HIGH to define a large 
return (Float)Cttiis.gctAttribute( "Balance- )); magnitude could translate into different values for different 
J uses. A HIGH temperature could be 95 while a HIGH 
— altitude could be 39000. 

. , *u A** . T^* . , J ^ In addition, constants often belong to logical groupings. 

Other methods on the AttributeDictionary mclude: ^^^^ stoCK, BOND, and OPTIONare 51 types of 

public void setAttnbute(Stnng attributeName, Float financial instruments. These belong in a some sort of col- 

attributeValue); lection, 

public void setattribute(String attributeName, String A consistent, quality method to represent constants in an 

attribute Value); g5 object-based system is required, 

public void setAttribute(String attributeName, Busines- Therefore, represent named constants in a separate class, 

sObject attribute Vahie); grouping categories of constant values together within one 
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-continued 



name space. Constants tend to naturally fall into logical 
groupings. Each grouping should be represented by its own 
class. For instance, all of-thCiConstants used by a Phone- 
Number object to capture the various types of PhoneNumber 
(i.e^home, business, faxrcell; pager, etc) can be accessed 5 
through a PhoneTypeConstants class. 

If constants are obtained by other means than explicit 
language constructs like "public final int HOME__ 
ADDRESS" than public accessors are used to insulate a 
client from changes in how the constant is obtained. In this lo 
case the vahies of each of the constants should be defined 
privately inside the Constant Class. Public accessors are 
then provided for clients to obtain the constant values. This 
allows for "changing constants'*. Business-related values 
that may seem constant at design and construction time very 
often are not. Some of these "constants" may eventually 
require some logic to determine their value. If clients obtain 
constants through accessor methods, no changes (except 
within the accessor) will have to be made if the logic is 
added. This is a particularly safe practice when program- 
ming rules dictate all constants to be stored and retrieved 
from database tables. 

In the case where constants are defined within the class 
itself most 00 languages, excepting Smalltalk, allow for ^yP® partition is used by PhoneNumber. See main( ) 

some type of const definition. In this case by using a const 25 for uncommenting a line that demonstrates the type safety 



private final int phoneNumbeiTypcOrd; 

private final String typeld; 

private Phonet«fambeiiype^t i. String id) { 

phoneNumbeiT^peOrd = i; 

typeld ■» id; 

types .addElement(tlii5); 

} 

public final static Emimeiation eleinents( ) { // allows for 
enumeiation 

return types.clcmcnts( ); 

public static void niain(String args[]) { 

Enumeiation elements = PhQneNuihbeiType.element8( ); 

PhoncNutnbeiiype pt; 

while (eleinentsJiasMoreElements( )) { 

pt = (PhoneNumbeiT^pe)cIemcnts.nextEIemcnt( ); 

Systein.ouLprintlnQ)ttoString( )); 
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} 



} 

public String toString( ) { 
return typeld; 



35 



construct (i.e. static final int PhoneNumberiype FAX=n6w 
PhoneNumberType( )) it is not necessary to have public 
accessors and private definitions. Declare the class type, 
create static final instances of the type and do not provide a 
public constructor. This ensures the type safety and provides ^ 
easy to access members in the Eiffel style. 

Moreover, public accessors in either strategy provide for 
type-safe enumerations. Enumeration is a special type of 
constant that deserves attention. A TypeConstant class can 
provide enumeration by implementing some key methods 
that provide for supporting iteration over the elements of the 
enums. In Java, for example, this entails implementing the 
Enumeration interface. 
Benefits 

40 

Maintainability. Groups all valid vahies together and 
ensures they can not be created or passed as parameters 
by any other method. 
Type Safety. Enumeration values can be type-checked by 

a compiler in method parameters and return values. 45 
A common ^plication pattern where this use of constants 
was applied was in the modeling of instances vs instance 
types where the types added no additional behavior. In two 
different customer care applications this came through as the 
objects like PhoneNumber, PhoneNumberiype, RatePlan & 50 
RatePlanType, etc. This example has not yet been updated to 
JavaBeaos. 



protection through the use of static final and private con- 
structors. 



package Party; 

import javaio.PrintStieam; 

import java.io.StringWriter, 

public class PhoocNumber 

{ 

private PhoneNumbcriype phoneNumbeiTypc; 

private String arcaCodc; 

private String prefix; 

private String suffix; 

public PhoneNumber( ) { 

areaCode - null; 

prefix - nxill; 

s uffix a mill; 



package Party; 

import java-util.*; 

public dass PhoneNximberType { 

static final Vector types - new Vector( ^ 

static final PhoneNumbeiTVpe FAX - new PhoneNumbeiTVpe(0, 
"Fax^ 

static final PhoneNumberType CELL = new PhoneNumberTVpe(l, 
"CeU Phone"); 

static final Phonebfumbefiype HOME = new PhoneNumbciTVpc(2, 
"Home'O; 

static final PhoneNumberTVpe WORK = new PhoncNumbciType(3, 
•^oritO; 

static final PhoneNumbciType PAGER = new PhoneNumberTypc(4, 
"Pagcr^; 
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public PhoneNuniber(StTing aPhoneNumber) 

paisePhoneNumber(aPhotteNumber) ; 
sctPhoneNumberType(PhoneNumberTVpcJIOME); 

public PhoncNuniber(String anAieaCode, String aPrefix, String aSuffix) 

arcaCbde « anArcaCode; 
picfix o aPrefix; 
suffix ■=■ aSuffix; 

public String arcaQ)dc( ) 

return arcaCodc; 

public void areaCodc(String anAieaCode) 

areaCodc - anArcaCode; 

public boolean equals(String aPhoneNumber) 

PhoneNumber tempPhoneNumber - new 
PhoncNumber(aFhoneNumber^ 

return equals(tempPhoneNumber); 

public boolean equaIs(PhoneNumber aPhoneNumber) 

if (areaQ)de( ) = null && aPhoneNumbcr.areaCbde( ) 1= null [1 
aPhoneNumbcLaieaCode( ) =- null && areaCode( ) !» null) 
return &lse; 
if (areaODdc( ) != null) 
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{ 

if (aTeaQ)de( ).equal5(aPhoneNuinber.aieaCode( )) && 
prcfix( ).equaIs(aPhoiieNuinberptcfix( )) && 

sufiSx( ).equal&(aPhoneNuinbei:suffix( ))) 
return true; 

else 

return &lse; 

} 

if (pre&s( ).c(iuals(aPhoneNumbcr.prefix( )) && 
suSx( ).eq[uals(aPhoaeNumber.sufl5x( ))) 
letuni tnie; 

else 

return &lse; 
> . . . 

public static void main(&ring argv[]) 
{ 

PhoneNumber aPhoncNumbcr; 

SystenLout.printlii(*Tfesting construction & conqjarisonl'^; 
if (argv.Icngth = 0) 

{ 

Systein.out.piintln(*Tfest with no area code - no masks"); 

aPhonel^fuinber - new PhoneNumbcrC'5579203"); 
aPhoncNambcr^tPhoneNuinbciType(PhoneNumberTypeJAX); 

System.ouLprintlD(aPhoneNuaabeLtoString( )); 

System.ouLprintln(*Te8t with area code - no masks"); 

aPhoneNumber = new PhoneNumbcr('*2065572039^; 
aPhoneNumber.setPhoneNumbeiTVpe(PhoneNumberType.WORlC); 

System.outprintln(aPhoneNumber.toStnng( )); 

SystenLouLprintin(*'7^t with normal masks'^; 

aPhoneNumber = new PhoneNumber(''(206) 557-3920"); 
aPhoneNuniber.setPhoneNumbciTypc(PhoneNumbciTypeJ*AGER); 

System.outprintln(aPhoneNuinbei:toString( )); 

System.ouLprintln("Tfest equality 5578215 557-^5"); 

PhoncNuinber tempi = new PhoncNximber("5578215^; 

ten:5>l-setPhoiicNumberTypc(PhoneNumbciTypc.CELL); 

PhoneNumber tcmp2 = new PhoncNnmber(**557-8215*^ 

ten^2.setPhoneNumbcrType(PhoneNumbeiType.CELL); 

// temp2..setPhoneNumberTypc(new PhoneNunibcrType(6, 
"^Y")); // cnum type safety w/private ctor 

System.ouLpiint!n(temp] ); 

SystenLoutprintIn(tcmp2); 

System.ouLprintlii("tcmpl = temp2: " + 
tempi .equai8(tcmp2)]t 

return; 
}else{ 

aPhoneNumber - new PhoneNumber(aigv[0]); 
SystenLoatprintln(aPhoneNumbei:toString( )); 



} 



} 



private void par8ePhoneNumber(StTing aPhoneNumber) 



{ 



StringBufFer aStr = new StriiigBuflrer(aPhoneNumbcr.lcngth( )); 

int i = 0; 

do 

if (CharacteusDigit(aPhoneNumbcLcharAt(r))) 
aSttappcnd(aPhoncNumber.charAt(r)); 
while (i-H-<aPhoneNuniberJength( ) - 1); 
String tempString = new String(aStrX 
if (aStr.length( ) = 7) 



{ 



} 



prcfix(tempString.5ubstring(0, 3)); 
suffix(tcmpStringjsubstring(3, 7)); 



} 



areaCode(tenipString.substring(0, 3)); 
prefix(tcmpString.substring(3, 6)); 
sufl5x(tempString^bstring(6, 10)); 



public String pFefiz( ) 



{ 
} 

public void prefix(String aPrefix) 



return prefix; 



prefix =» aPrefix; 



• This method was created by a SmartGuide. 

• @param sw StringWriter 
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15 



V 

public void printOn (StringWriter sw) { 

8W.WTite(((areaCode t= null Q areaCode =-"")? ("(** + 
areaCode( ) + 

sw.write(this,prefix( )); 
sw.writc("-"); 
sw.write(this.suffix( )); 
return; 

} 

public void setPhoncNumbefI^(PhoneNumbeiI^e pnt) { 
phoneNumbciiype » pnt; 

public String suflSx( ) 
{ 

return suffix; 
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} 

public void su£Sx(String aSu£5x) 
{ 

} 



suffix — aSuffix; 



' + ((areaCode 
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public String toString( ) 
{ 

return new Stiing(phDneNumbeiTVpe.toString( ) + * 
!= null II areaCode — "") ? ("(" + 
areaCode( )+")"):**") + prefix( ) + -wuffix( )); 

25 I 



Alternatives 

Smalltalk allows for grouping logical constants in Pool- 
Dictionaries as in TextConstants. This is simply a global 
dictionary with key value pairs that simplifies and improves 
readability by using well understood names like "Space** and 
"Tab". However, they are global variables and they are not 
automatically recreated when you file in code that depends 
on them. 

When constants are implemented in a class within Small- 
talk accessors must be used. There is no real language notion 
of firud or const in Smalltalk that would allow for accessing 
member variables. 

Communications Services Patterns (1008) 

An original tenet of component-based design has been 
simplified distribution of functionality. According to the 
original argument, up-front definition of component bound- 
aries and their interfaces would simplify the configuration of 
functionality on the network. Even though component-based 
45 design has simplified distribution, it has not guaranteed 
success. Networks introduce performance issues and failure 
conditions that didn't exist in non-distributed solutions. If a 
solution is to be successful, these issues can't be ignored. 
Each pattern in this section addresses a difficulty assod- 
50 ated with distributed computing. Every pattern reflects a 
problem and a solution to issues enootmtered by other 
development teams. 

Legacy systems rurming on mainframes^ Unix boxes, etc. 
are an important part of today's client projects. The majority 
55 of today's clients have existing computer systems that 
cannot be easily rewritten or ignored. Integration of these 
older systems with the newly developed applications is often 
imperative to the success of the project. Any newly devel- 
oped components must leverage the existing fimctionality on 
these Legacy systems. The Legacy Wrapper pattern 
addresses this problem. It describes a common pattern for 
tackling the integration issues associated with reusing fimc- 
tionality from existing systems. 

Server-side components implement services for use by the 
65 Clients in an application. These components should clearly 
specify the interfaces and services they provide, but how 
should they make them available? A well-known central 
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service, e.g., a Name Service or Trader Service can be used object-based systems. In a third situation, both of the sys- 

to make the interfaces available to all Clients, but is that tems may be non-object-based systems, 

always wananted or prudent? Should every Client have Stream-based communicatioD is a very effective pattern 

access to every service? The Locally Addressable Interface for relaying data, data structures, and meta-data. Meta-data 

(LAI) and Globally Addressable Interface (GAI) patterns 5 is information about the data like data structure, data types, 

describe two approaches to this pr(*lem. using a shared, generic format. How can the message 

The performance characteristics of remote components format be shared between systems so as to create the most 

are very different from "in process" components. The cost of straightforward and best performing stream-based mecha- 

requesting and transmitting data between remote compo- ^^^f - • 

nents is much higher and should be considered in a distrib- lo . ^ determined that a stream-based communica- 

uted solution. As a result, distributed solutions often call for mechanism should be u^ to transport information 

communication patterns that improve upon the performance between systems. Stream-based ^mmunication is a pattern 

aspects most important to the system. TTie Stru^ Based ^i^^^iZlf.t^^ one system to aiioter 

J J ^. a L n . usmg a Simple Stream and a shared format to relay the data 

Commum™ pattern addresses he "chattiness" associ- ^^^^ ^^^^^^ information. ^ 

ated with distributed apphcations. It helj^ reduce network is piG. 66 illustrates two systems 6600 communicating via 

load and increases system response Ume. TTie Paging Com- ^ stream-based communication 6602 and using a common 

munication pattern addresses the common need to retrieve generic format to relay the meta-data information 

and di^lay large lists of data. It shows how incremental However, when implementing Stream-based 

fetching can be used to provide much better perceived Communication, a number of factors influence the method 

responsiveness in GUI based applications. 20 for enabUng each system with a "shared format." The 

The cost of locating a remote service and establishing a "shared formar provides the meta-data information needed 

connection to that service can also be a costly endeavor. The to interpret the raw data in a stream. This shared format is 

Refreshable Proxy Pool pattern describes a robust and like a secret decoder ring for systems sending and receiving 

efficient way to minimize this "lookup" activity. messages. It allows the systems to convert stmctured data 

Most recent component-based systems use middleware 25 (objects, strings, etc.) into raw data and raw data bade into 

such as CORBA, DCOM or Java RMI to specify the strucdired data. This is needed to transmit the structured data 

interfaces provided by components and the associated data across the network. 

types. However, such middleware is not always available, or many projects, the following factors influence the 

directly apphcable. In such situations the Stream Based details of communicating using a stream. 

Communicationpattem,oroneof its descendants, the Fixed 30 High performance — System performance is always a 

Format Stream and Self describing Stream patterns might be factor, but sometimes it is one of the most important 

applicable. These patterns describe different techniques for factors in a system. 

efficiently streaming data between processes. While they aU Short development time — ^The system must be opera- 
share a common solution to a common problem, the solu- tional in the shortest possible timeframe, 
tions present different tradeoffs between implementation 35 Stable information characteristics — In some solutions, die 
simplicity, performance and flexibility. data and the structure of the data are stable and unlikely 

A Null value represents the "empty set" and is an impor- to change, 

tant value in distributed component solutions. In cases like this, how can one optimize the benefits of 

Some languages, such as Java, support NuU as a ^ecific stream-based communication and implement only the most 

value, whereas other languages do not (e.g., C++ which uses 40 basic capabilities that one requires? 

zero and context to determine NuU). This language mis- Therefore, use the Fixed Format Stream pattern to create 

match can cause problems in distributed systems that use a stream-based message that uses fixed format contracts to 

more than one language. The Null Structure pattern share the formatting information and meta-data between 

describes this problem and proposes a solution. systems. 

Fixed Format Stream 45 Fixed format contracts are maps that contain the meta- 

FIG. 65 illustrates a flowchart for a method 6500 for data information such as the data stmcturc, data separators, 

providing a fixed format stream-based communication sys- data types, attribute names, etc. They describe how to 

tem. In operation 6502, a sending fixed format contract on translate Fixed Format messages onto a stream and off of a 

interface code is defined for a sending system. A receiving stream. 

fixed format contract on interface code is also defined for a 50 FIG. 67 illustrates an example of a Fixed Format message 

receiving system. A message to be sent from the sending 6700 associated with the fixed format stream patterns. The 

system to the receiving system is translated in operation location and size ofeach attribute in the message is fixed and 

6504 based on the sending fixed format contract. The known at design time. In the example below, it is known that 

message is then sent from the sending system and subse- the command will be in bytes 1-9, the first name will be in 

quendy received by the receiving system in operations 6506 55 bytes 10-29, the last name in bytes 29-^9, etc. This infor- 

and 6508. The message received by the receiving system is mation (meta-data) is used by the Fixed Format contracts to 

then translated based on the receiving fixed format contract convert Fixed Format messages from data structures to raw 

in operation 6510. data and back again. 

In one embodiment of the present invention, information FIG. 68 depicts the complete Fixed Format Stream pattern 

in the translated message received by the receiving system 60 associated with the fixed format stream patterns. A data 

may also be stored in a relational database. In one aspect, the stmcture on System A 6800 is translated to a Fixed Format 

fixed format contracts may be included in meta-data of the message (raw data) using a Fixed Format contract. The 

message. Also, in another aspect, the message may inchide message is put in the stream 6802 and sent to System B 

an indication of a version thereof. 6804. System B 6804 receives the Fixed Format Message 

In one situation, one of the systems is an object-based 65 (raw data) and uses its Fixed Format contract to recreate the 

system and one of the systems may be a non-object-based data structure. The same process works in reverse when 

system. In another situration, both of the systems are may be System B 6804 responds to the message request. 
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Benefits 



Performance. Because there is no time spent on look-ups 

or dynamic translation of the message, performance is /*• stream my attribute values on astream •*/ 

better than with other variations of Stream-Based Com- public void streamOn (Outputsticam aStream) 

munication. { 

aStrcam.writc(this.getName( ).asString( ).pad^^SpaccsClO)); 

Small Message Size. Each Fixed Format message con- aStrcam.write(this.gctSex()^striiig().padvwtliSpaccs(7)); 

tains only data to be sent to the other system. These aStream.write(this.getAge( ).asStriiig( ).padWithSpaces(3)X 



messages contain no meta-data and are smaller than 
those in Self-Describing Streams. lo 



} 



Simplicity. Translating and parsing information onto and ^* stream is then put into a message communication 

off of the stream is straightforward and easier than with mediaiiism like MQSeries or MessageQ and sent to the 

the other variations of Stream-Based Communication. non-object system. 

The behaviors for the Fixed Format Streaming are ^- ^® non-object system, interface code reads 

contained in the fixed format contracts on the interfaces through the stream, parses the values off of the stream, 

of the sending and receiving systems and thus easy to converts them to the appropriate types if required, and 

find. puts them in a copybook with the appropriate structure. 

Object Friendly. This pattern is very straightforward to ?° example, the fixed format contract is embodied 

implementinobjectbasedsystems.Tlieobjectscontain !?^^.^,/Ji'i!^!^!!^'?^ ^^HPe of the WS-SHARED- 

the fixed format contracts and manage the translation FORMAT-CUSTOMER working-storage copybook, 

and parsing onto the stream. These objects can access ^^^^"^ pseudo-COBOL example below, 
their own private behaviors whidi makes the interface 

much simpler. 

Implementing this pattern is very straightforward. Define 25 • ■ • 

corresponding fixed format contracts on the interface code data diyision. 

of both the sending and receiving systems. FIG. 69 iUus- ^ file-stream-in 

trates fixed format contracts 6900 containing meta^iata RECORD cx>otains 20 characibrs 

information for translating structured data onto and off of a working-storage section. 

stream. ^ Tins copybook Contains the common format of 

In non-object systems, define a fixed format contract on ™^ 

the paising i^erface module of d,e sending sy^en.. n.e Z'^^,^'^^^'^'''^^ 

mtertaang module on the sending system can use the 03 ws-oommon-format-name picx(io> 

contract as a map for how to translate and write the data onto 03 ws-COMMON-format-sex pic x(7). 

the stream. Define a corresponding fixed format contract on ^ ws<X)MMON-FORMAr-AGE pic 999. 

the interface modules of the receiving system. The interface ;Y^<^^k is -nns sysiems view of a customer 

module on the receiving system can use the contract to read 03 ws-name pic x(io). 

and translate the data off of the stream. 03 ws-age pic 999. 

In object-based systems, make each object responsible for ^ ws-SEX pic x(io). 

its own fixed format contract. Using this contract, each ^ procedure division 
object is able to retrieve and parse its attribute values onto 

a stream as strings (streamOn) and each object class should *** open the file stream and put the contents in the 

be able to parse attributes off of a stream and put them into w&common-format-customer copybook. 

^"r'jT'"",^ - ""j^'^'/^^O^, Afco. it ^. good ^Si5X^:S,^W«X>MMON-FO«MAr- 

practice to mclude the version of the format withm the customer 

stream so that concurrent format versions can be accommo- at-end close file-stream-in 

dated in the design. end-read. 

Below is a pseudo-code example of an object-based ^^VE toe values into from the common format 

system communicating with a non-object system using the ws-customer variables. 

stream-based communication and a fixed format contract. move ws-common-format-sex to ws^ex. 

HG. 70 illustrates a Customer object 7000 in an object- ws^mmon-pormat-age to ws-age 

based system 7002 streaming itself into a stream 7004, the wscommon-format-name to ws-name. 

stream being sent to a non-object system 7006, diis stream caul A sql module to save this informahon in 

being read and the data inserted into a relational database THE 

7008. *•* RELAnONAL DAIABASE 

1 TV, * . , -,u -u . ^ CALL "SAVE-CUSrOMER-tN-DAFABASE" USING WS- 

1. 1 ne CustomerObject with attributes name, sex, and age customer. 
has a method "streamOn: aStream," It is invoked with 

an empty stream as the argument *aStream'. The Cus- sroP RUN. 

tomerObject "streamOn: " method goes through each of ' ' 

the object's attributes and parses each values as a string 50 Conversely, a stream could be created by a non-object 

onto the stream. system (or another object-based system for that matter) and 

The fixed format contract here is embodied in the order sent to one's object-based system. In this case, Customer- 

that this method parses the attributes onto the stream. A Object could use a "streamOff: aStream" method and instan- 

pseudo-code example in Java is the following: Note- tiate a new instance of an aCustomerObject and populate it 
Assume that "asString( )" converts the receiver to a 65 with the appropriate attribute values, 

string and that "padWithSpaces( )''pads the string with Eagle Architecture Framework: Uses Stream Based Com- 

^aces and makes the string the length specified. munication in a number of ways. First of all, it uses it 
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to embed tracing information in CORBA distributed In a typical two or three-tiered client-server application, 

requests. Second of all, it is used to replicate state the services are maintained away firom the usere (Client) on 

between fault-tolerant services. separate Server machines. Whenever a user needs to use a 

Ma: Invoice Development Workbench. This workbench service, the user must send a request across the network to 
helps MCI create error-free invoice definitions for the 5 the Server machine. 

various Local Bells. Stream-based commimication was Before a client can utilize a service, it must find the 

used as part of an efficient, lightweight persistence service. If the client is unable to find the service, it can't ever 

mechanism. use it. FIG. 72 depicts a cKent 7200 that is unable to find the 

Java Serialization: This is a Java defined fixed format for services provided by a server 7202 via a network 7204. 

streaming objects. The cUent could look for services in a naming service. 

Object Request Brokers (ORBs) that use CORBA, However, if the services don't exist in the lookup or naming 

DCOM, or Java Remote Method Invocation (RMI>— service, the client still can't find and use the service. 

ORBs that use one of these standards implement this Therefore, use a Globally Addressable Interface to expose 

pattern. They define an Interface Definition Language services to all available cUents. 

ODL) that is the format or contract of the stream and a Globally Addressable Interface builds upon the Inter- 

S^n Si ^"^"^"^'^^^^^ ^ commumca- fa^e pattern and the Naming pattern. When iiiplementing a 

Collaborations Globally Addressable Interface, a Server's operations are 

Stream-based Communication. TTiis is the parent pattern ^""^ the Interface pattern. 

to Fixed Format Stream. In this pattern, information is . ^J?' ^^'^^^^^ ^he groupmg of services 7302 using 

transmitted using a simple stream and a shared, generic ^ "itertaces 7304. 

format. The Fixed Format Stream is a more specific imple- example, all the operations for accessing and viewing 

mentation of Stream-Based Communication. customer information (Get Customer, Get Customer 

Structure Based Communication — ^This pattern uses a Address, etc.) could be bundled into one interface. All the 

Fixed Format Stream to transmit data structure between operations for changing customer information (Change 
systems. It is often used to obtain data from a Server for 25 Customer, Address, Change phone number, etc.) might be 

display in a Client UI. bundled into another interface. Keep in mind, this is an 

Bridge (from the Gamma book Design Patterns) describes example "bundling" of operations and not the definitive 

a way to de-couple an abstraction from its implementation method for bundling operations. 

so that the two can vary independently. The Bridge pattern Once all the operations have been grouped into an 
is often used to define collaborations between a business 30 interface, the interface is given a name appropriate to the 

object and a format object while decoupling the business operations it bundles. Then the interfaces are aimounced 

object from its specific stream format. using the Naming pattern. The Naming pattern enables 

Abstract Factory (from the Gamma book Design Patterns) registration of interfaces in a gld)ally available naming 

is a pattern for creating families of related classes. This service. FIG. 74 illustrates a customer server 7400 is pub- 
could be used with the Bridge pattern to retrieve the format 35 licly announcing its interfaces 7402. 

dynamically based on non-static information. Until that time, a client can't find the operations and can't 

Alternatives use them. Thus, the Server must use the Lookup or Naming 

Self-Describing Stream. This pattern is a specific imple- pattern to register its interfaces (not methods). Once the 

mentation of Stream -Based communication where the mes- interfaces have been registered with such a service, any 

saging format is parameterised and stored on the stream. A 40 client can go to the Naming Service, locate an interface, and 

message language is used to read and write the format of the access an operation in that interface, 

message from the stream. Benefits 

Downloadable Format Stream — ^This pattern is a specific Public Addressability — ^Every Globally Addressable 

implementation of Stream-Based communication where the Interface is publicly available for use by any client. As 

messaging format is stored at a central location and is 45 a result, any Client can find these interfaces and access 

downloaded by the communicating parties when needed. these operations. 

Globally Addressable Interface Stateless Load Balancing. Globally Addressable Inter- 

FIG. 71 illustrates a flowchart for a method 7100 for faces are generaUy implemented for stateless Servers. 

deUvering service via a globally addressable interface. A When Stateless Servers arc used, it is a lot easier to 

plurality of interfaces are provided in operation 7102 and 50 balance the incoming load. Since state or context is 

access is allowed to a plurality of different sets of services always passed into the Server, any call can be directed 

from each of the interfaces in operation 7104. Each interface to any Server that supports a particular operation. If one 

has a unique set of services associated therewith. Each of the is busy, the Client can be forwarded on to the next one. 

interfaces is named in operation 7106 with a name indicative The following is a message trace diagram depicting the 

of the unique set of services associated therewith. The names 55 interactions associated with a Globally Addressable Inter- 

of the interfaces are then broadcast to a plurality of systems face. 

requiring service in operation 7108. The Message Trace diagrams depict a common Oient- 

The access may be allowed via structured-based commu- Server scenario. A client requests customer data from a 

nication. As another option, the names may be broadcasted Server. The Server finds the data in a database and forwards 

using a naming service. Also, the naming service may 60 it back to the client. The CUent can then display the data in 

provide the systems requiring service with a location of the a User Interface for a user. 

interface on a network. In addition, the systems requiring The scenario was broken into two message trace dia- 

service may be capable of looking-up the interfaces using grams. The first message trace sets the stage for the second, 

the naming service. In the first message trace, the Server registers two Gldially 

In a client-server environment, a cHent makes requests of 65 Addressable Interfaces with a Naming Service. The CHent 

services on a Server. In such an environment, how might a then "looks-up" an interface and establishes a connection to 

Server expose its services for use by one or more clients? that interface. 
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Assumptions 

CORBA ORB connects Client and Server 
CORBA Naming Service used to lookup GAIs 
FIG. 75 illustrates a method 7500 including the register- 
ing and then locating of a globally addressable interface. 
Collaborations 

la. "Bind" the interface name (Update Interface) with it's 
Remote Object Reference (network location) in a Naming 
Service. This will allow clients to "lookup" the interface. 
Once the Interface is registered in the Naming Service, it 
has become globally addressable. Any client can find the 
interface and access a operation. 

lb. "Bind" the second interface in the same manner as the 
first. 

2. The client instantiates a Proxy (Browsing Interface Proxy) 
to the Browsing Interface on the Customer Server. 

3. The Proxy "looks up" the network location of the Brows- 
ing Interface. It makes a request of the Naming Service. 
It requests the network location of the Browsing Interface. 

4. The Naming Service returns the Remote Object Reference 
(network location) for the Browsing Interface. The Proxy 
now has all the information it needs to access an operation 
on the Browsing Interface. 

Hie second message trace builds upon the first. In this 
message trace diagram, the Client calls the Server through a 
Globally Addressable Interface. The server finds the appro- 
priate customer data and returns it to the Client. The Client 
can then display it in the UI. 

FIG. 76 illustrates the present invention using a method 
7600 wherein a globally addressable interface is used to 
obtain data from a server. The steps associated with the 
method 7600 of FIG. 76 will now be set forth. 
Collaborations 

5. The Client a^ the Browsing Interface Proxy for the data 
associated with customer 1234. 

6. The Browsing Interface Prpxy forwards the request across 
the network to the Browsing Interface. 

7. Same as 6. 

8. The request is forwarded to the Customer Server. The 
Customer Server requests the customer data from the 
Database. 

9. The Database returns the customer data for Customer 
1234. 

10. The Customer Server creates a structure and populates it 
with the customer data. 

11. The Customer Structure is forwarded through the Brows- 
ing Interface, across the network and back to the Brows- 
ing Inlcrf ace ^xy. 

12: The Browsin^nterfacc Proxy forwards the Customer 
Structure jpi^e^Client, The Client can now display the 
data in a^UI' for a user. 
IDL Interfaces and Structures 

The following IDL defines the two Interfaces and Struc- 
tures used in the message trace diagram s above. 
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-continued 



// CORBA IDL for the Browsing Interface 
inteifEice QistomerBrowsinglnterface 



10 }; 



}; 



coimnonDefs::Cu5tomerStiucture getCiistomer(long anid); 
coimnoaDefs::AddressStructuie getAddrcss(Iong anId); 
stiing gctPhoneNumber(long anId); 



25 



// "niis module defines the stiuctures passed through the two // customer 
interfaces. 

module commonDefa 
{ 

struct AddressStructure 
{ 

string street; 
string city; 
stiing state; 
string zip; 

string phoneNumber, 

}; 

struct CustomerStructure 
{ 

string id; 
string status; 
string firstNaroe; 
stiing lastN^ame; 



}; 
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Sample Code 

The following is some Sample Java code for the Skeleton 
portion. 



35 



40 



45 



//Pass all requests on to the Component for processing 
public CustomerStructure getQi8tomer( 
String aCtistomerld) 



{ 



CustomeiComponent aQistomerComp = this.getCbmponent( ); 
retum(aCustomeiCDmp.getCustomer(aCustomerId)); 



//Pass all requests on to the Component for processing 
public String getPhone(Stiing aCustomerld) 



} 



The next sippet of code is for the Customer Component 
(Server). The interface delegates the processing to the com- 
ponent. 



50 



module QistomeiServer 
{ 

// CORBA IDL for the Update Interface 
interface QistomerUpdatelnterfaoe 

void changeOistomer( long aiJd, 
oommonOefaiKI^tomerStiucture aCustomer); 

void chan^Address(long anId, 
commonDeferAddressStructurc aNewAddress); 

string changePhoneNumber(long anW, string 
aNewPhoncNumbcr); 
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// Get the Customer's data and return it 

public QistomerStructore ge^^Ustomer(String aCustomerld) 

// Go to the database and get the 

// customer with the apptopimtc ID 

Customer aCustomer » „. 

// Create a structure and populate it with the 

// customer data retrieved from the DB. 

CustomerStructure aQistomerStructure - new 
CustomeiStiuctuic( ); 

aCu8tomerStructure.id = aCustomer.gctId( ); 

aCustomerStnicture.status — aCustomer.getStatus( ); 

aCustomerStructure.firstName » 
aCiistomer.getFtistName( ); 

aCustomerStructure.lastName « 
aCustomer.getLastName( ); 

return (aCustomerStructurc); 
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As an option, the legacy wrapper may include a legacy 

-continued wrapper component coupled to a component adapter which, 

— — — — — — — — in turn, may be coupled to a legacy adapter via a legacy 

pubhc strmg getPhone(Stnng aCustomerid) integration architecture. In this ipect, the legacy adapter 

5 may also coupled to the legacy system. As another option, 
the component adapter may also reformat call parameters of 

} the message into an acceptable format for the legacy system. 

pubUc AddressStiuctuie getAddrcss(striiig aCustomerid) As an additional Option for this aspcct, the legacy wrapper 

^ component may also include a pure legacy wrapper com- 

ponent. As even a further option to this aspect, the legacy 

} wrapper component may include a hybrid legacy wrapper 

— ^ . component. Also, the interfacing may further include: send- 

A^j-*- 1 ^ J ^ message from the client to the legacy wrapper com- 

AddiUon^ Considerations , ^ ^ ^ ^.^ ponent via the component integration aTchiiecftirersending 

Hie GA^ class is actuaUy r^re^nted by two different the message via the component adapter to the legacy inte- 

wf^ST"^' "^J" g^^^-^ architecture; forwarding the message to L legacy 

a Pro^ and a Skeleton Tbe Proxy represents the interface adapter, formatting the message to an appKcation 

on a Ghent while the Skeleton represents the mterface on a p^gram interface (API) of the legacy system; executing 

r *hrt ti* ^° ^® legacy system based on the formatted message; 

couaDoranons executing function of the calls and returning results to the 

■ ^"7:7 f^-'''7. ^ 1? ^''^ ^ l^g^^y ^^Pt^^' l^ga'^y integration architecture, component 

ni^te from a Ghent to a Globally Addressable Interfece on adapter, and legacfw^apperl^mponent which i^formVte the 

Structure Based Cbmmunication-^ften times, a client 7^1^: ^t^'^'^'f^^ the reformatted results to the cHent 

needs to display daU in a UI for a user (e.g. Customer ^^P^°^°^ integration architecture 

Information, Order Information, etc.). When communicating ^^^^^^ systems pose a unique situaUon for developers of 

through a Globally Addressable Interface, this data is trans- ^ component-based solutions. Commonly hosted on 

mitted from the Server to the Client using Stmcture Based mainframes. Legacy Systems often communicate through 

Communication. proprietary protocols, have no standard data or process APIs 

Load Balancing—When a number of servers implement ^ integrate easily with component based systems, 

the same Globally Addressable Interface, the Load Balanc- ^^^^ ^ developer access a Legacy System in a 

ing pattern is used to balance Client requests between these ^ component-based solution? 

Servers. A legacy system is an existing system that does not 
Proxy Pool — The Proxy Pool pattern helps balance the conform to the technology, architecture and standards of the 
cost of instantiating Remote Proxies and retaining Proxy current project. A large IBM 3090 Mainframe running 
"freshness." The Proxy Pool pattern can be used to create a programs to calculate automobile insurance rates is an 
pool of Proxies to Globally Addressable Interfaces. 35 example of a Legacy System. It is large, very important to 
Locally Addressable Interface — ^Locally Addressable an insurance company, and runs on older, proprietary hard- 
Interfaces are private interfaces that aren't easily located. ware. 

Generally, a well-known interface (like a Globally Addres- Legacy Systems generally utilize different communica- 

sable Interface) is used to find a LAI. A Client easily find and tion protocols than those used by newly developed compo- 

access a service on a Globally Addressable Interfaces and 40 nent systems. As a result, communicating between a newly 

request a reference to a Locally Addressable Interface in developed component and a Legacy System is very diflficult. 

return. FIG. 78 depicts the communication difficulties associated 

Interface— The Interface pattern defines methods or func- with Legacy Systems 7800 attempting to commimicate with 

tions or services rather than implementation. The Interface a client 7802 via a component integration architecture 7804. 

pattern is expanded upon by the Globally Addressable 45 The newly developed application (cHent and components) 

Interface pattern. communicates through a different protocol than the existing 

Naming— The Naming pattern describes a pattern for Legacy System. FIG. 78 illustrates heterogeneous Interfaces 

registering and finding services or objects etc. where they from Components. 

can be easily found in an application. The Naming pattern is Legacy Systems are critical to an organization and usually 

often used to register Globally Addressable Interfaces so 50 represent a significant investment. They are tightly con- 

they are publicly available. trolled to reduce the incidence of system failures and clients 

Alternatives may be unwilling or unable to replace these older systems. 

Locally Addressable Interface— The Locally Addressable New applications could be developed on the mainframe 

Interface pattern is both a collaborating and alternative system, however, this generally is not considered strategic 

pattern. It can be used to retrieve infonnation from Servers 55 and takes a lot of time and effort. Organizations want to add 

instead of Globally Addressable Interface. new functionality (new processes) without investing in the 

Legacy Wrapper old legacy system. 

FIG. 77 illustrates a flowchart for a method 7700 for As a result, the current Legacy Systems represent signifi- 

affording access to a legacy system. A plurality of compo- cant investments, are often crucial to a business and aren't 

nents coupled to a chent via a component integration archi- 60 easily replaced. Investing in new Legacy applications isn't 

techire are provided for servicing the client in operation practical or strategic and Legacy Systems can't communi- 

7702. A legacy system is interconnected to the client via the cate with newer componentized systems, 

integration architecture using a legacy wrapper in operation Therefore, the component-based solution should use a 

7704. In operation 7706, the legacy system and the client are Legacy Wrapper to communicate with the existing Legacy 

interfaced via the legacy wrapper by communicating with 65 Systems. The Legacy Wrapper is a component built to adapt 

the client by way of a first protocol and by communicating the front end of a legacy system to the rest of the component- 

with the legacy system by way of a second protocol. based solution. 



us 6,636,242 B2 

217 218 

Ibis solution encapsulates the concerns of a Legacy The Legacy Integration Architecture (8016) is responsible 

System away from the new application. It allows other for sending and receiving messages between the server 

components in the solution to communicate with the legacy and host machines. This architecture is usually based 

component in the exact same manner as the rest of the on some specific communication implementation, 

component-based solution. Further, this solution can also be 5 Examples of this include message queues and common 

used to partition the existing Legacy System functionality. databases accessible by both legacy systems and 

FIG. 79 illustrates homogenous inteif aces from components component-based solutions. 

7900 which rectify the problems with Legacy Systems 7901 The Legacy Adapter (8018) is a custom component 

attempting to communicate with a client 7902 via a com- re^onsible for translation from the particular imple- 

ponent integration architecture 7904. mentation of the Legacy Integration Architecture to the 

Benefits Legacy System. 

Reuse. The Legacy Wrapper pattern allows reuse of an The Legacy System (8020) is the existing system that will 

existmg Legacy System. New component applications be accessed by the newer component-based solution. 

can be developed that leverage the rich store of busi- Changes to the Legacy System should be minimized 

ness processes and data that already exist on the Legacy when accommodating the new component-based solu- 

System. 15 

Migration. Allows for slower migration of functionality The application on the host is responsible for translating 

from the Mainframe to components. By continuing to messages between the Legacy Integration Architecture and 

use the functionality of the existing legacy system, the the Legacy System. For example, tbc application must know 

immediate need to build the same functionality in a how to format calls to CICS appropriately, as well as 

pure component-based solution is lessened. ^ interpret results and reformat them in a way appropriate for 

Encapsulation. Provides a separation of concerns between Legacy Wrapper server component 

the new system and the Legacy System. By encapsu- ^^^^ *° ^^^^^ wrapper components are Re- 
lating the Legacy System, the impact of host changes is cialized to partition the fimc^onality of the existing legacy 
largely limited to the Legacy Wrapper. fT^"* ^t^T* 
Hie implementation of Legacy Wrapper is usually very ^ Legacy Wrapper Component 
specific to the type of Ugacy System it is integrating. The type is the Pure Legacy Wrapper Component. This 
implementation in this section attempts to give a high level component simply adapts the lega^ system to the new 
overview of the components of typical legacy systems. component-based solution. No new busmess processes are 
HG. 80 shows how a Legacy Component is integrated added m interface metho^ on the Legacy Wrapper Com- 
into a component-based model 8000. ^30 Po^ent "pass tough" to the legacy system, as shown m 
The upper part of FIG. 80 depicts the main units 8002 of 81 illustrates legacy Wrapper Components of 
a component-based solution. The lower part of the picture Wrapper Component mcluding a Legacy 
depicts the Legacy Component 8004 in greater details. Wrapper Component 8112, a Component Adapter 8114, a 
nie foUowing is a description of the participants in the ^^^^ titegraUon Architecture 8116, a Ugacy Adapter 
upper portion of FIG. 80. f?!^'. ' ^^^"^ ^^^^"^ 

TTieQient (8006) is the application mnning on the user's "^"l^^'Z. 7r n . • u 

machine. It is respons^le for UI presentation, local „ ^./^.p^^^^ ^KTr"' "^"^ 

business objects, and communication using cUent resi- Hybnd component. FIG. 82 illustrates a Hybnd Component 

dentproxi^ type of Legacy Wrapper Component. As shown, the hybnd 

rru *i* *• Ai.-. /o-wwox . u ^ includes a Legacy Wrapper Component 8212, a Component 

Tlie Component Intepation Architecture (8008) is the ^^.p^^^ 8214, a Legacy Integration Architecture ffil6, a 

component that allows chents to commumcate and Le Adapter 8218, and a Legacy System 8220. 

remotely mvoke fiincUons on the server components^ It is a mix of legacy system adapter and some new 

lypically this is based on some middleware standard u-u- -i *o 

fJ^ nAuTiA \jrrc\ busmess processes built m a smgle component. Some of the 

te.g.,CUKBAor Ml^). 45 interfaces 8222 of the wrapper component 8212 "pass 

Hie Components (8010) m this FIG. 80 represents the through" to the legacy system, while other interfaces com- 

server components. These are the busmess entity com- municate with objects, which may in turn call the legacy 

ponents and the business process components. They are system. 

invoked from the Qient via client proxies. j^^^ ^re potentially more variations, including use of an 

From the outside, the Legacy Component 8004 looks 50 Event Service to allow the mainframe to initiate work from 

identical to any other component. However, internally is the wrapper components, 

performs a very specialized function. Example 

.J^^^^' ^ ^^^"^ ^^^"^ Component pic. 83 shows an abstract example of the control flow in 

8004. The expansion shows the mdividual elements, which a Legacy Component. Although, the example is at a very 

comprise the Legacy Component 8004. These elements are: 55 high fevel, it should provide some insight as to how the 

The Legacy Wrapper Component (8012) is rc^onsible Legacy Cbmponent functions and how it invokes work on 

for presenting the same functionality provided by the the legacy system. 

legacy system to the rest of the component-based From the example of FIG. 83, the following steps are 

solution. Other components of the new component- shown: 

based sohition will interact and communicate with this eo 1. The Client component wants to invoke some 

component. Although this component wraps the exist- functionaUty, which is located on the legacy system. The 

ing legacy system, it should behave as any other Client sends a message via the Component Integration 

component m the newer sohition. Architecture (e.g. ORB) on the way to the Legacy Wrap- 

The Component Adapter (8014) is a custom component per Cbmponent. 

responsible for the translation from the Legacy Wrap- 65 2. The Component Integration Architecture (e.g. ORB) 

per Component to the particular implementation of the forwards the call to the appropriate Legacy Wrapper 

Legacy Integration Architecture. Component. 
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3. The Legacy Wrapper Component sends the call via the 
Component Adapter to the Legacy Integration Architec- 
ture. AVhen necessary, the Component Adapter reformats 
the call parameters into an acceptable format for the 
Legacy System. 5 

4. The Legacy Integration Architecture receives a call for the 
host-based Legacy application and forwards it to the 
Legacy Adapter. 

5. The Legacy Adapter receives the message from the 
Legacy Integration Architecture and formats it to match lo 
the API of the Legacy System. It makes the appropriate 
calls on the Legacy System. The Legacy System executes 
the function and returns the results to the Legacy Adapter. 

6. The Legacy Adapter receives the results and returns them 
to the Legacy Integration Architecture. 15 

7. The Legacy Integration Architecture receives the result 
and fonvards it to the Legacy Wrapper Server Component 
through the Component Adapter. 

8. The Legacy Wrapper Component receives the result, 
reformats the parameters for the component system and 20 
forwards it to the Cbmponent Integration Architecture. 

9. Finally, Component Interaction Architecture receives the 
result and forwards it to the Client. 

Collaborations 

Message Queued Legacy Integration is a specific imple- 25 
mentation of this pattern. It uses message queues as the 
legacy integration architecture. 

Adapter (&om the Gamma book Design Patterns) 
describes at a more abstract level how to convert the 
interface of a class into another interface that clients expect. 30 

Proxy — This pattern is documented in Design Patterns by 
Gamma, Helm, Johnson and Vlissides. The proxy pattern is 
often used to communicate with server components in a 
distributed environment. The Proxy would be \ised to com- 
municate across the Component Integration Architecture to 35 
a Legacy Wrapper. 
Alternatives 

Screen Scraping is a more ^ecialized version of legacy 
wrapping. It describes how to convert a user interface to that 
of the server (i.e., the legacy system in this case). In this 40 
solution, the host-based application generates 3270 type 
screens and then passes them to CICS. The advantage of this 
solution is that it is non-invasive to CICS and reacts as if it 
were just another terminal interacting with CICS. This may 
be necessary with legacy systems which must be leveraged, 45 
but can not be modified and provide no common API set 
Locally Addressable Interface 

HG. 84 illustrates a flowchart for a method 8400 for 
delivering service via a locally addressable interface. In 
operation 8402, a plurality of globally addressable interfaces 50 
and a plurality of locally addressable interfaces are provided. 
Access is allowed to a plurality of different sets of services 
&om each of the globally addressable interfaces and the 
locally addressable interface in operation 8404. Each inter- 
face has a unique set of services associated therewith. In 55 
operation 8406, the globally addressable interfaces are reg- 
istered in a naming service for facilitating access thereto. 
Use of the locally addressable interfaces is permitted only 
via the globally addressable interfaces or another locally 
addressable interface in operation 8408. 60 

In an option, the use of the locally addressable interfaces 
may be facilitated by structured-based communication. As 
another option, the access may be allowed via a customer 
interface proxy, a customer server and a database of the 
globally addressable interface. 65 

In one embodiment, a request may be received by the 
customer interface proxy for a reference to one of the locally 
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addressable interfaces. The request may then be forwarded 
across a network to the database of a server of the globally 
addressable interface. Also, data from the database may be 
returned in re^onse to the request. Additionally, an object 
may be instantiated and populated it with the data by the 
server of the globally addressable interface. The object may 
also be associated with one of the locally addressable 
interfaces. Also, the locally addressable interface may be 
forwarded to the globally addressable interface. As even a 
further option, a reference may be forwarded to the locally 
addressable interface across the network and to the customer 
interface proxy. In addition, the use of the customer interface 
proxy may be also used to access the locally addressable 
interface across the network. 

In a client-server environment, a client makes requests of 
Services on a Server. In such an environment, how might a 
Server expose its services for use to a client in a tightly 
controlled manner? 

Quite often a component wants tight control over the 
visibility of its interfaces or does not have a need to make its 
interfaces widely available. Examples of such situations 
include: 

Security — A component may provide multiple interfaces, 
some of which have sensitive operations that should not 
be exposed to all clients. For example, an insurance 
company's customer service desktop application gets 
fiill access to all interfaces and services on a Customer 
component, but an Independent Agent application has 
restricted access to services. 

Interface Design — From a design standpoint it may make 
sense to limit access to some interfaces. For example, 
a system operations interface might allow clients to 
query Server components for the number of requests 
being serviced, or disable future requests on a particular 
Server. In this type of situation, it's best to limit access 
to the appropriate user group. In this case, the opera- 
tions tools specifically designed for administering a 
system. 

Large number of interfaces — If the component design 
caUs for a large number of interface instances (objects), 
then it would be detrimental to use the GAI pattern. The 
sheer number of interfaces could overcrowd and over- 
burden the Naming or Trader service. The Naming or 
Trader service would slow down as it searched its large 
list of entries. Additionally, the system would slow 
down as every client attempted to access the Naming or 
Trader service for every interface. 
Thus, it's sometimes best to keep interfaces with limited 
appeal out of a Naming or Trader Service. 

No need — If a particular interface or service only has one 
client, why bother registering it globally? It doesn't make 
sense and causes additional administration. 

FIG. 85 illustrates Problems with Globally Addressable 
Interfaces in a system 8500 including clients 8502 and 
servers 8504 with a plurality of interfaces 8506. 

The last couple of points are quite common for statefiil 
components. The above samples clearly do not call for the 
GAI pattern — an alternative manner of making interfaces 
available to clients is required. 

Therefore, the Locally Addressable Interface pattern 
should be used to control access to interfaces in an efiScient 
marmer. 

FIG. 86 illustrates the manner in which the present 
invention uses a Locally Addressable Interface 8600 to hide 
functionality and lessen the load on the Naming or Trading 
Service 8602. 

All components maintain a Globally Addressable Inter- 
face 8604 This interface is registered with a Naming or 
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Trader service 8602 and can have any of its services 
accessed by any client on the network- The services on a 
GAI 8604 are generally stateless and potentially shared by 
many clients. 

Locally Addressable Interfaces 8600 are not registered 
with a Naming or Trading service 8602 and can only be 
obtained through a Globally Addressable Interface 8604 or 
another Locally Addressable Interface 8600. 

FIG. 87 illustrates the manner in which the present 
invention obtains a Locally Addressable Interface 8700. 

Globally Addressable Interface 8702 services typically 
are used to obtain Locally Addressable Interfaces 8700 by 
providing some key information to the service, trigger 
global changes to all of the component's member objects, or 
to obtain component-maintained data that is not represented 
by a Locally Addressable Interface 8700. 

It is important to note that member business objects are 
never directly exposed to the client but, rather, communi- 
cated with through a component interface (global or local). 
This allows for changes to be made to the internal structure 
of the component without disturbing the way a client inter- 
faces with the component. Encapsulation is preserved. 
Benefits 

Tight control. Servers providing LAIs have fill control to 
determine whidi clients will receive them. This control 
could, for example, be based on client type, access 
rights or server load. 

No central bottleneck. The pattern does not rely on a 
centralized service to hand out interfaces. This leads to 
a scalable architecture that can handle many interface ^ 
instances. 

Useful for stateful components. Stateful components 
often contain many objects, each accessed through a 
separate interface instance. The LAI pattern is very 
useful in such circumstances. 
Cbmplex server side relationships. The LAI pattern is 
better for managing complex object relationships than 
most alternatives. If an object is associated with a lot of 
other objects (an order holds a customer and an address 
and a line item etc.), it isn't practical to copy all of the 
objects to the client. 
The following is a message trace diagram depicting the 
interactions associated with a Locally Addressable Interface. 

The Message Trace diagrams depict a common Client- 
Server scenario. The Client would like to interact with a 
specific Customer on the Server. The client requests a 
Locally Addressable Interface to a Customer Object on the 
Server and communicates with that object. 

The scenario was broken into two message trace dia- 
grams. The first message trace sets the stage for the second. 
In the first message trace, the Server registers a Globally 
Addressable Interface with the Naming Service. The Glo- 
bally Addressable Interface will be used to get the Locally 
Addressable Interface. 
Assumptions 

CORBA ORB connects Client and Server 
CORBA Naming Service used to lookup GAIs 
FIG. 88 illustrates the method in which the present 
invention registers and then locates a Globally Addressable 
Interface 8800. The various steps shown in FIG. 88 are set 
forth hereinbelow. 
Collaborations 

la. "Bind" the interface name (Customer Interface) with 
it's Remote Object Reference (network location) in a 
Naming Service. This will allow clients to "lookup" the 
interface. Once the Interface is registered in the Nam- 
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ing Service, it has become globally addressable. Any 
client can find the interface and access a operation. 

2. The client instantiates a Proxy (Customer Interface 
Proxy) to the Customer Interface on the Customer 
Server. 

3. The Proxy "looks up" the network location of the 
Customer Interface. It makes a request of the Naming 
Service. It requests the network location of the Cus- 
tomer Interface. 

4. The Naming Service returns the Remote Object Ref- 
erence (network location) for the Customer Interface. 
The Proxy now has all the information it needs to 
access an operation on the Customer Interface. 

The second message trace builds upon the first. In this 
message trace diagram, the Client calls the Server through a 
Globally Addressable Interface. The server finds the appro- 
priate customer data and instantiates an object with the data. 
A Locally Addressable Interface to the specific Customer 
object is then returned to the Client. Hie Client can then 
directly access the specific Client through the Locally 
Addressable Interface. 

FIG. 89 ilustrates the manner in which the present inven- 
tion uses a Globally Addressable Interface 8900 to obtain a 
Locally Addressable Interface 8902 to a specific Customer 
Object 8904. Note the steps set forth below. 
Collaborations 

5. The Client asks the Customer Interface Proxy for a 
reference to a Locally Addressable Interface for Cus- 
tomer 1234. 

6. The Customer Interface Proxy forwards the request 
across the network to the Customer Interface. 

7. The request is forwarded to the Customer Server. The 
Customer Server requests the customer data from the 
Database. 

8. The Database returns the customer data for Customer 
1234. 

9. The Customer Server creates instantiates an object and 
populates it with the customer data. The Customer 
object is associated with a Locally Addressable Inter- 
face (Update Interface). 

10. The Locally Addressable Interface is forwarded to the 
Customer Interface. 

11. The Customer Interface forwards a reference to the 
LocaUy Addressable Interface, across the network and 
back to the Customer Interface Proxy. 

12. The Customer Interface Proxy instantiates an Update 
Interface Proxy with the reference to the Update Inter- 
face. 

13. The Customer Interface Proxy forwards the Update 
Interface Proxy to the Client. 

14. The Client sends a new address for the customer to the 
Update Interface Proxy. 

15. The Update Interface Proxy forwards the information 
across the network to the Update Interface. 

16. The Update Interface forwards the new address to the 
Customer Object The Customer Object updates its 
address based upon the new information. 

Collaborations 

Proxy — The proxy pattern is generally used to commu- 
nicate from a Oient to a Locally Addressable Interface on a 
Server. 

Interface — ^The Interface pattern defines methods or func- 
tions or services rather than implementation. The Interface 
pattern is expanded upon by the Locally Addressable Inter- 
face pattern. 
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Globally Addressable Interface— Locally Addressable middleware. FIG. 91 illustrates the problem associated with 

Interfaces are private interfaces that aren't easily located. sending a NULL across many types of middleware 9100 
Generally a weU-known mterf ace (like a Globally Addres- ^system should be able to take advantage of this impor- 

sable Interface)isusedtofindal^^AChentcanea^^ tant value and use middleware that may not support it 
and access a service on a Globally Addressable Interface and 5 ^ 
request a reference to a Locally Addressable Interface in Therefore, use the Null Structure pattern to pass a struc- 

retum ^""^ ^ is Null attribute across the middleware. Unlike 

Structured Based Communications— Often times, a client ^ "nuU", a structure can be passed across the middleware, 
needs to display data in a UI for a user (e.g. Customer FIG. 92 ihistrates the manner in which the present inven- 
Information, Order Information, etc.). When communicating lO tion passes a "null" structure across the middleware 9200. 

'^''!V^'^^'^'''^"^Jl°'''^''"''^o^''^**^'"^ The extra attribute on the structure then determines 

mitted from the Server to the Client usmg Structure Based ^^^^^ „^ „„, ^ ^^^^ represents a "nuU" value. Tlie 

Commumcation. ♦ ^ • j . •• - . , 

Alternatives stmcture can be quened to determine whether or not it 

r^\^u 11., Ajj ™ ui T * _f -n- ^1 i_ 11 represents a "null" value. FIG. 93 depicts conveisations 

Globally Addressable Interface. The Globally Address- 15 oiwi „ ... « n*, j * * ^ g^T . • 

ui T * _f ** • i_ *t. 11 1. J y^nn with a null data structure 9302. FIG. 94 deoicts 

able Interface pattern is both a collaboraUng and alternative „ „ „„ , , ~ ^^ZT 

u J * * * • r r ^ conversations 9400 with a non-"nuIl data structure 9402. 

pattem. It can be used to retrieve information from Servers olxu^iui^ 

instead of LocaUy Addressable Interface— the right choice '^^ ^ attribute could be added as shown in the IDL 

will depend on the context. example below. 

Null Structure 20 

FIG. 90 illustrates a flowchart for a method 9000 for 

communicating a null value. A query is first communicated structure contract 

in operation 9002 from a first system to a second system to { 

determine whether a data structure is a null value. Next, in boolean isNuU; 

operation 9004, a rei^nse to the query is received from the 25 ^^J^^^' 

second system indicating whether the data structure is a null doAk rate; ^' 

value. A request for the data structure is sent from the first }; 

system to the second system in operation 9006 only if the Benefits 

response indicates that the daU stmcture is not a null value. S^^' ^ ^ ^ "^^^ ^'^ 

Subsequently, the data structure is received from the second 30 components. 

system in operation 9008. 

As one option, the rei^nse may be a Boolean indication. The following example assumes a CORBA implementa- 

As another option, the response may be determined based on tion. In order to pass Null Structures across an ORB, a 

an attribute of the data structiire. As a fiirther option, the data structure must be defined in the ORB's interface definition 

structure may represent a set of a plurality of values. Also, 35 language (IDL). The following IDL defines a structure that 

the first system may, optionally, be a client and the second will represent an Integer or a "null." 
system is a server. 

When transmitting data across a network between a client 

and server application, the middleware's "type system" does — — ^— — ^— 
not always support null values. How can a remote service 40 Commonlnteger 



send or receive null values over a communications medium 



{ 



long vahie; 

that does not support them? boolean isNuU; 

It is expected that distributed Business Components will }; 
collaborate with other Business Components via some sort " 

of communications medium. Communications between 45 » j x .t. ^ . . ^ . 

nr.».^r.^r.i<. rs^f u^^A\ A u *u 4 lu thc codc that pTOparcs thc data to bc scut ovcr the ORB, 

components is not usually handled by the components , ^u^^x. «f ♦k- • a j *u ^ • t . 1 

themselves but rather by some communications middleware '^'^.f and the structure .s populated 

(like an object request broker; or ORB). appropnately If i ,s null. Uie is NuU flag ,s set otherwise it 

A"null" valuel a frequently used value in object-based ^"^^ «""Pl*= 

systems. A "null" represents the empty set. It is often so 

returned from a service that is unable to find the requested . 

elements or is used as an optional parameter in a distributed public Commonlntcgea^ converUntcgerFoiORB(Integer anlnteger) 

service. For example, a Cfient might request all the custom- { 

ers with a last name of "Smith." If no Customers exist with tfTnfa*"^"^— intcgciStmcture = new Conimonintcger( ); 

a last name of "Smith," a "null" value would be returned. 55 { (anlnteger null) 

Some legacy systems return -999 or 0 when no data mtegeiStmcture.isNiill - true; 

exists. This is not an ideal solution as the system is using } 
data to represent non-data. What if -999 or 0 are valid 

responses to a request? Instead, a "null" could be used to integerStmctuicisNuU - feise; 

better represent this case. A "null" value provides extra 60 integerStructure.value - anIntege^.int^^( ); 

flexibihty since a specific data value need not be reserved to } 

represent the empty set. integerStructure; 

However, middleware cannot represent every data type t 

that exists in every language. Since middleware is "language 

neutral", it can only represent the least common denomina- 65 The receiving code that obtains the data from the ORB 

tor of every language accessible via the middleware. Due to does the same conversion in reverse as shown in the method 

this constraint, "null's" often can not be represented in below: 
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public Inte^r coavert[ntegerFiDinORB(CommonInte^r 
anlntegerStiucture) 



Integer anlnteger = auU; 
if (anIntegeiStnicture.isNuU 



} 



felse) // structure not null 
anlnteger = new Integer(anInte^rStructure.value); 



} 



return anlnteger, 



Collaborations 

Proxy. A Proxy is a placeholder that can accept requests 
meant for another object. This is typically used in distributed 
systems when one component wants to send a request to 
another. Thus, a proxy is often used to make request of 
servers that may return null structures. 

Client-Server. Client-Server is a type of architecture that 
separates of Client portion of an application from the 
business logic or database portion of an application. When 
implementing a Client-Server application, the Client and 
Server often communicate across a middleware (like 
CORBA) that doesn't support "nulls." 
Alternatives 

Invalid Value. Determine an "invalid value" for each data 
type in the particular apphcation. Return the "invalid value" 
when ever a null should be returned. 
Paging Communication 

FIG. 95 illustrates a flowchart for a method 9500 for 
transmitting data from a server to a client via pages. In 
operation 9502, pages of data sets are built from data in a 
database of a server. Upon receipt of a first request from a 
client for the data in the database of the server in operation 
9504, a first one of the pages of the data sets is sent to the 
client over a network in response to the first request in 
operation 9506. When a second request from the client for 
the data in the database of the server is received in operation 
9508, a second one of the pages of the data sets is then 
transmitted to the client over the network in response to the 
second request in operation 9510. 

The second request may be sent to the server with an 
identifier of a last entry of the first page. Also, a size of the 
data sets of the pages may be defined dynamically. As an 
option, the pages may be delayed by the client upon receipt 
from the server. Also, a size of the data sets of each of the 
pages may be determined based on a user interface of the 
client. As another option, a size of the data sets of each of 
the pages may be determined based on an amount of data 
capable of being displayed at once by the client. 

In a cHent-server environment, a client often needs to 
display or process a long list of data. Finding and transmit- 
ting this list of data can take a long time and negatively 
impact the user's response time. How can a client and server 
interact to improve the user's response time when retrieving 
a large list of data? 

The speed with which a UI can respond to a "user 
initiated" request is important. TTiis is generally called the 
UI refuse time and is an important attribute of every 
application. FIG. 96 depicts the response time 9600 for a 
User Interface 9602 to display a list of customers in a list box 
9604. 

Users expect an "acceptable" level of UI response in their 
applications. i^pUcations that don't meet this criteria, will 
not be successful. 

Many UIs allow users to query databases for lists of data. 
In FIG. 96, for example, the user elides the "Get Customers" 
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button to initiate a database query. The query will retrieve 
every customer from the database and the UI will display the 
customers in a list box. The user can then scroll through the 
data and select a particular entry for further investigation. 

FIG. 97 shows a request that returns a large amount of 
data. As shown, in a three-tiered client-server environment, 
each query must travel from the client UI 9700, across a 
network 9702, to a Server 9704, and eventually to a Data- 
base 9706. Then, the result of the query must travel all the 
way back to the client. 

When the query results in a large amount of data, the time 
to search the database and return the data across a network 
can become prohibitive. As a result, the UI response time 
will quickly degrade to an unacceptable level. 

To make things worse, the average user only looks at half 
of the data returned from the database. The user is just as 
likely to find their data in the first half of the list as the 
second half of the list. As a result, the user may wait a long 
time for data that is not used. 

FIG. 98 shows a graphical depic^on of a paging commu- 
nication pattern 9800. 

Therefore, provide Paging Communication between the 
client and server tiers of an application. Paging Communi- 
cation describes a pattern for transmitting a large amount of 
data while maintaining an acceptable UI response level. 

Rather than send all of the data at one time, a subset or 
"page" 9802 of data is transmitted. When the cUent needs 
more data, another "page" 9802 of data is transmitted. This 
continues until the client has seen enough data or all the data 
has been transmitted. 
Benefits 

More Responsive UI. This pattern improves upon the 
user's response time. The server only retrieves and 
transmits a "page" of data at a time. This is a lot faster 
than retrieving and transmitting all of the data at one 
time. The pattern breaks-up the total search and trans- 
mission time into smaller page-sized chunks. This 
greatly improves upon the user's perceived perfor- 
mance. 

Additionally, the Server searches the database for a 
"page" of data at a time until the user finds what they 
are looking for. As a result, unless the needed data is in 
the last page of data, the search is limited to a portion 
of the total seardi. 

Configurable Page Size. The page size can be "timed" to 
best fit the application. As a result, the page size can be 
altered to best fit a particular network, application 
design, etc. 

Stateless Servers. The paging mechanism can be managed 
from the client-side requester. Thus, this pattern can be 
used with stateless servers just as easily as with stateful 
servers. 

UI TUnable. The page size can be changed to match a 

particular User Interface, 
list Box Friendly. A list box can only display a limited 
amount of data at one time. As a result, it isn't as 
important to have all of the data immediately available 
for the list box. The List box can display a page of data, 
and then request additional pages of data as the user 
scrolls through the list. 
Scenario: A user is searching for a particular customer. 
TTie user doesn't remember the exact name of the customer, 
but the user believes they will recognize the name when they 
see it. Thus, the user requests a list of all customers. 



us 6,636^42 B2 



227 



228 



Technical Parameters 
Static Page Size=4 

List Box can only display 2 lines of data at a time. 

FIG. 99 illustrates a message trace diagram showing the 
interactions between a Client 9900 and a Server 9902 using 
Paging Communication to satisfy the previously mentioned 
scenario. 
Definitions 

Starting Key 

The Starting Key is the initial starting point for the search. 
The database will begin searching for data (customers 
in the message trace above) at the Starting Key. An 
example starting key could be "A***. 

Last Found Key 

The Last Found Key is used to request subsequent pages 
of data from the Server and the database. The "last 
found key" defines the starting point for the next data 
request. The Server will begin searching for data at the 
"last found key" and continue until it has retrieved a 
full "page" of infomiation. 

When all of the data has been retrieved from the Server 
and Database, the Last Found Key is left blank. This 
notifies the Client that all the data has been sent. 

Intermediate Page 

An intermediate "page" is returned for every request but 
the last. When a client receives an intermediate page 
and a "last found key", the chent knows more "pages" 
of data exist on the server. 

In order to obtain an intermediate "page," a "last found 
key" must be passed from the client to the server. When 
the Server has retrieved a fiill "page" of data, the new 
"last found key** is saved. It is then passed back with the 
intermediate "page." The new "last found key" defines 
the starting point for the next data request. 

Last Page 

When the Server has retrieved all of the data meeting the 
search criteria, the Server builds the last "page." When 
the last page is returned to the client, the "last found 
key" is left blank. This notifies the client the search is 
complete and no more data matching the search exists 
on the Server. Note that the last page is usually smaller 
than the other pages. 

Empty Page 

When no data are selected from the search criteria, the 
server builds an empty page signaling to the client no 
more data exist on the server. 

Static or Dynamic Page Size 

The page size can be defined statically or dynamically. 
The message trace diagram in FIG. 99 depicts a sUtic 
page size. 

If you*d Like a dynamic page size, the client must pass an 
additional parameter with each request to the Server. 
The additional parameter would be the page size. 

The steps associated with FIG. 99 will now be set forth. 
Collaborations 

1. The user "clicks" the "Get Customers" button on the 
User Interface. The Client UI makes a getAllCustomers 
request of the Server and passes a Starting Key as a 
parameter. Since the user wants to view all of the 
customers, a Starting Key of spaces is used. Message 
sent-getAllCustomers(" "); 

2- The Server receives the request from the Client. The 
Server realizes the Starting Key is blank and knows this 
is a new request. Thus, the Server requests first four 
customers (the page size) from the database. 
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3. The database returns the first four customers (Albert 
Abraham, Ned Abraham, Sally Abraham and Alice 
Allen) and a "Last Found Key" ("Alice AUen**) to the 
Server. The "Last Found Key" denotes the last entry 
found during the search. It will be used for subsequent 
searches. 

4. The Server builds a page with the four customers 
retrieved from the database. The Server returns the 
page and the Last Found Key to the Client 

Page Type«Intermediate 

Page="Albert Abraham", "Ned Abraham", "Sally Abra- 
ham" & "Alice AUen" 
lastFoundKey=" Alice Allen" 

The Chent receives the "page" of data. The Client sends 
the data to a UI List Box for viewing by the user. The User 
can see the first two customers (Albert Abraham, Ned 
Abraham). 

The User clicks the "scroll down" arrow twice and can 
now see two additional customer (Sally Abraham, Alice 
20 Allen). 

5. The User clicks the "scroll down" arrow again. No 
more data exists on the Client so the Client must 
request another page from the server. The Client UI 
makes a getAllCustomers request of the Server and 
passes the Last Found Key of AKce Allen. Message 
sent«getAllCustomers("Alice Allen**); 

6. The Server receives the request from the Client. The 
Server requests the next four customers (page size) 
after Alice Allen. Message sent=getPageOfcustomer 
("Alice Allen") 

7. The database returns the next four customers (Jason 
Allen, Fred Allen, Sam Allen & ZackAllen) and a "Last 
Found Key" ("Zack AUen") to the Server. 
The Server builds a page with the four customers 
retrieved form the database. The Server returns the 
page and the Last Found Key to the Chent 
Page Type=Intermediate 

Page=."Jason AUen", "Fred AUen", "Same AUen" & 

"Zack AUen" 
lastFoundKey="Zack AUen" 
The Client receives the "page" of data. The CUent sends 
the data to a UI List Box for viewing by the user. The 
User can see the first two customers and one new 
customer (Alice AUen, Jason AUen). 
The User can now scroU through the next three customers. 
When scrolling past customer Zack AUen, the Client 
will request another page of data from the Server. It wUl 
foUow the same basic pattern as described in steps 5-9, 
EventuaUy, the end of the list of Customer will be reached 
n-3. Once again, the client clicks the "scroU down" arrow 
and no more customers exist on the client. The Client 
must request another page from the server. The Client 
UI makes a getAUCustomers request of the Server and 
passes the Last Found Key of Jim Ziegler. Message 
sent=getAllCustomers("Jim Ziegter**); 
n-2. The Server receives the request from the Client The 
Server requests the next four customers (page size) 
after Jim Ziegler. Message sent-getPageOfcustomer 
("Jim Ziegler") 
n-1. The database can only find two more customers. The 
database returns the final two customers (Sam Ziegler 
and Ziggy Ziegler) and no Last Found Key. 
n. The Server builds a page with the two remaining 
customers retrieved from the database. The Server 
returns the page and the blank Last Found Key to the 
Ghent. 
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Page Type=Lasl Page ladistiibutedsystems with many clients, it is important to 

Page="Sain Ziegler", "Ziggy Ziegler" establish connections with remote servers in an efScient 

lastFoundKey=" " manner. In a manner where clients evenly utilize the avail- 

The Client receives the final "page" of data. The Client able servers. How can this be performed in a consistent 

sends the data to a UI List Box for viewing by the user. 5 manner for all clients? 

The User can see the following two customers (Jim In production systems it is quite common for long-lived 

Ziegler, Sam Ziegler). clients to "stay up" for days and interact with a collection of 

The User clicks the "scroll down" arrow once and can dififerent servers. Oftentimes, a client process will establish 

now see the final two customers (Sam Ziegler, Ziggy connections to the same type of server a bunch of times 

Ziegler) in the List Box 10 during its lifetime. The lifetimes of the client and its servers 

Subsequent "clicks" on the scroB down arrow no longer f?, often different as a result of seiver maintenance and 

request data fiom the Server. TTie Client knows (duTto ^"Z^ However, such failures should have mjmmal impact 

the blank last found key) that it has already received all r'!„^,;''lHL^hl^ 1*^..^ sj^tems usually retneve a 

of the available data. Addressable Interface (GAl) from a nammg or 

Additional Details 15 ^"a /a^'^J ^Tk r „ . u u 

Cbntext isn't generaUy stored on the Server when imple- „.^^^,7'^T^''?' " fT 7^,T IK^T^ 

menting Paging Commuidcation. As a result, it is imporLt ^>i°''"^ ^'"^'"'^ Trader Service 

to requestTminimum coUection of data from the «n,er. ^u,.^- wrapped up m a pro 2) Invocations 

Most of the relational database are using a count mechanism °J r *^'='!E:°*^"PP°^«» *f 3) Release 

that defines the maximum number of data to search. Tlat 20 P"^/ ^^1" often means a long-hved client will 

-11 * * • r^rai j repeatedly ask the Trader Service for the same tvpe of 

will mmimize CPU and memory usage. f ^ j • i -r 

A t-j-*u 1- Lj.-.. mterrace during its lifetime. 

As explamed in the example, page size may be adapted to ™^ ia< Ti * * * j ^ . .1. r,. j ^ 

*u 1- * • * i_ *!. * J . FIG. 101 illustrates repeated requests to the Trader Ser- 

the chent requirements, however that does not mean the ^AiAn r *i- ^ wuis, ^<ius>i os^i 

^r^^ ™,^# ^^fi.rfi* fk M ♦ - 11 «u 1' « 10100 for the same mterfaces are neither efficient nor 
page size must exactly nt the widget size. Ideally the cuent 

application will anticipate future user actions and request 25 °^^f!!yiji„ „„„^„4* ♦u - * ^ c j 

more than one page. ^ Repeatedly requesting the same mterfece from a Trader 

Collaborations Service is neither efficient or necessary. However, the Trader 

m. 4.^ ' a, ji ^ ' . Service does maintain load balandng information and allo- 

Proxy— The Proxy pattern is often used to communicate 1 4 u • * -r * • ^ouu tm^i 

between Oients and Servers in a distributed environment. A ? "Ti ""^ ^""^^ * 

Proxy is often used to make requests for a "page" of data 30 T^^'^'S^"- i, 1 ^ • u 

ftom a Server Therefore, use a Refreshable Proxy Pool mecharusm that 

Interface Control Model-The ICM pattern addresses the "I^T^^fir T^"' f v°n '?k °f 

separation of the Interface (Viewing portion) fiom the ^ ? k k ^' ^ 

Control fiom the Model (the data portion) man application. f^f'" l™t of Proxies to renioteser^ces usu^ some 

n . ^ • • li J V . 1 sort of a Lookup Service (e.g. Trader Service. Naming 

Paging CommunicaUon is often used when implementing 35 « • \ in. nJ^ n 1 *« ? u . l ^"^ 

♦L- ZL r f A *• r* A *u u r . Service). The Proxy Pool will hold onto these Proxies and 

thisscparaUonoffiinctionahty. A user through the Interface ,ii™*/*u^ * * *u ^ *u ti7i_ "i^ 

^ ^ * r J . J , allocate them to Clients as thev need them. When the chent 

uses the pattern to retneve large lists of data from the Model ^ , ^ ^ ^ " 1 u ^ T 

for viewine ^ * proxy, the pool will hand out a new 

Proxy 

In.?^^^1 Addressable Interfao^tobaUy Addressable p,^ jj,^^^,^ 

Interfaces are often used to obtain a Page of data from a 40 ^ • vaiv« mat 

Server for display in a OientUL . Tf"^' . , ^ , u o_ „ . 

Alternatives In order to balance the system load evenly, the Proxy Pool 

Paging with Server Caching-TOs pattern builds upon f*/^. f^IfT' " B^«=i°g W^*"* («=g- Ro«nd 

the Paging Communication pStem. R^her than querjdng R«*m) for handing out proxi» withm tfie pooL 

the daS: for a "page" of Momiation. the Server w^d 45 „ IPj^ has a "retirement age." Tie 

retrieve all of the data at one time. TTien the Server would ^"^^ age detennines the time to refresh a given 

pass the data to the Client one page at a time. Proxy. When a Proxy reaches ite retoernent age, U is taken 

Refreshable Proxy Pool °^ replaced with a freshly allocated Proxy. 

mo. 100 illustrates a flowchart for a method 10000 for ^^"^ ^/^l^"^^^^. "^S^f 

interfacing a naming service and a client with the naming so Tf*t', ^"^f ' ^t^einent 

service aUowing access to a plurality of different sets of Se'n^fiT" '"J^'^^^^y ""^ '^^^'"^ 

services from a plurality of globally addressable interfaces. _ - . t^- 

In operation 10002, the naming service calls for receiving Performance. Estabhshmg connections to servers wiU 

locations of the global addressable interfaces. As a result of time because chents will go to the trading 

the calls, proxies are generated based on the received 55 service less often. 

locations of the global addressable interfaces in operation Balanced Load. This ensures all clients are implementing 
10004. The proxies are received in an aUocation queue ^® strategy for utilizing available servers, 
where the proxies are then allocated in a proxy pool (see Standard. One single approach to pooling increases main- 
operations 10006 and 10008). Access to the proxies in the tainabiUty and predictability across the enterprise and 
proxy pool is allowed for identifying the location of one of 60 decreases confusion. 

the global addressable interfaces in response to a request Ease of use. Client developers do not have to design and 

received fi:om the client in operation 100010. implement their own version of pooling. 

The proxy pool may employ load balancing. As another Maintenance. This mechanism allows for centralized 

option, the proxies in the proxy pool may be renewed based development. When a bug is found it can be fixed and 

on an age thereof. As a third option, a handle may interface 65 distributed to all build centers, 

the proxy pool and the client. This handle may additionally Dynamic. Client threads will not have to worry about 

interface a plurality of the proxy pools and the chent. allocating retired or bad proxies. 
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Robustness. By pooling GAI location information, clients 
are less susceptible to Trader Service failure. This is 
because the Proxy Pool can operate using the GAIs it 
has information on for as long as those references main 
valid. 

The Proxy Pool should be packaged and distnbuted to 
client developers so that it is non-intrusive and easy for them 
to use. 

Parameters such as pool size and retirement age should be 
configurable. 

The client thread using the proxy should not pay a penalty 
for pooling or allocation. 

The pool should recover gracefully from server failure. 

The pool should recover gracefully from Trader Service 
failure. 

FIG. 103 illustrates the implementation of a Refreshable 
Proxy Pool 10300. The Refreshable Proxy Pool is based on 
a pool-queue approach. In this design, the pool holds allo- 
cated proxies 10302 while the queue allocates and replen- 
ishes the pool with proxies. To handle the allocation and 
replenishment, a worker or allocation thread 10304 runs on 
the queue and makes calls to the Trader Services as needed. 

There can be numerous proxy pools, but this implemen- 
tation supports typed pools Using C++ templates, i.e., each 
pool will only contain proxies of one type. This allows the 
client to create a class that is passed to the proxy pool and 
supports client specific properties in the pool such as pool 
size, retirement age, etc. Also, due to synchronization issues 
with the rest of the architecture, there can be only one 
aUocation queue. 

Qients who wish to use a pooled proxy will create a 
handle as a wrapper. This handle wrapper takes care of the 
problems associated with sharing resources across threads 
such as lazy initialization, reference counting, allocation, 
and de-allocation. 

Handles are classes that abstract the users away from the 
implementation. Handles are generally stack based and exist 
for the lifetime of a method invocation or an object The 
handle destructor insures that the underlying proxy is deref- 
erenced. 

Suggested Classes 

FIG. 104 illustrates the class relationships between the 
patterns primary classes. 
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Descdption 



5 PraxyHandle^> (10408) 



This is the Handle that clients should use to 
manage pooled proxies. The handles must 
use a static_cast-^ (C++ template) to 
retriew the correct proxy. T is defined by a 
client template Instantiation, and assumes the 
client knows exactly what type of proxy the 
pool is actually holding. Clients nmst take 
care to assure that pools only contain proxies 
of one type. 



Class 



Desca^tion 



PooledProacy (10402) 



ProxyPool (10404) 



AllocationPooI (10406) 



This is the base class for the pooled pro(xy. It 
actually acts as a wrapper for a Proxy and 
maintains all usage and reference counting 
informatioiL 

This is the proxy pool, vfhcrc clients go to 
retrieve a proxy. It should be thread-safe in 
that inult^)le threads are automatically syn- 
chronized. This pool should only contain 
valid proxies that have been allocated by 
the AllocationPooL When a proxy is 
requested, the usage count is incremented. 
After the 'Visage'* passes retirement age> the 
proxy is remove from the pool and placed 
bade into the allocation pool. 
This is the pool that actually does the proxy 
allocation. This pool is populated with un- 
allocated proxies and a "reader^ thread wfll 
allocate them. Since there will only be one, 
this class should be implemented as a 
Singleton. This poo! however can allocate 
proxies of any type. 



Collaborations 

15 Globally Addressable Interface — ^This is a pattern for 
making interfaces publicly available. Distributed connec- 
tions to Globally Addressable Interfaces can be pooled using 
the Refreshable Proxy Pooling pattern. 

Proxy — This pattern is documented in the book "Design 

20 Patterns** by Gamma, Helm, Johnson and Vlissides. The 
proxy pattern is often used to communicate with server 
components in a distributed envirorunent. Proxies are pooled 
using the Refreshable Proxy Pool pattern. 

Trader — The Trader service defines how distributed archi- 

25 lectures locate components based on the types of services 
they provide. The allocation queue interacts with a Trader 
Service to allocate the correct type of proxy. 

Naming — ^The Naming Service provides a mapping 
between names and object references. A Naming Service 

30 could be used to store the GAI references that the Refresh- 
able Proxy Pool pattern requires. 
Alternatives 

Single Use — As opposed to pooling cormections to a 
remote server a client can request a new connection each 

35 time a GAI is needed. This would work best when a client 
infrequently needs GAIs. 

Proxy Pool — This pattern addresses the pooling of prox- 
ies without periodic refreshing. It is a simpler version of the 
Refreshable Proxy Pool that may be of use when server load 

40 is fairly constant. 
Self-describing Stream 

FIG. 105 illustrates a flowchart for a method 10500 for 
providing a self-describing stream-based conununication 
system. Messages are sent including data between a sending 

45 system and a receiving system in operation 10502. Meta- 
data is attached to the messages being sent between the 
sending system and the receiving system in operation 10504. 
The data of the messages sent from the sending system to the 
receiving system is translated based on the meta-data in 

50 operation 10506. The meta-data includes a first section that 
identifies a type of object associated with the data and a 
number of attribute descriptors in the data. Also included is 
a second section that includes a series of the attribute 
descriptors defining elements of the data. 

55 As an option, the sending system and receiving system 
may each be equipped with logic for interpreting the meta- 
data of the messages. As another option, the elements may 
be defined in terms of size, type, and name. Versions of the 
present invention include a version where one of the systems 

60 may be an object-based system and one of the systems may 
be a non-object-based system, a version where both of the 
systems may be object-based systems, and even a version 
where both of the systems may be non-object-based sys- 
tems. 

65 Stream-based communication is a very effective pattern 
for relaying data, data structures, and meta-data. Mela-data 
is information about the data, such as data structure, data 
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types, etc. using a shared, generic fonnat. How can the 
message format be shared between systems so as to create 
the most flexible stream-based communicatioD mechanism? 

Often, it is determined that a stream-based communica- 
tion mechanism should be used to transport information 
between systems. Stream-based communication is a pattern 
where information is transported firom one system to another 
system using a simple stream and a shared format that relays 
both the data and meta-data information. 

FIG. 106 illustrates two systems 10600 communicating 
via Stream-Based Communication 10602 and using a shared 
generic fonnat to relay the meta-data information. 

However, when implementing Strcam-based Communi- 
cation 10602, a number of factors influence the method for 
enabling each system with a "shared format^ The "shared 
format" provides the meta-data information needed to inter- 
pret the raw data in a stream. This shared format is like a 
secret decoder ring for systems sending and receiving mes- 
sages. It allows the systems to convert structured data 
(objects, strings, etc.) into raw data and raw data back into 
structured data. This is needed to transmit the structured data 
across the network. 

Many additional factors influence the detailed design of 
this communication mechanism. Some systems support 
volatile and constantly changing object models, data models 
and data stmctures. In these systems, flexible, de-coupled 
communication is extremely important. 

In a constantly changing system, a statically defined 
"shared format" doesn't work very weU. Every change to the 
object model, data model of data structure causes a reimple- 
mentation of the "shared format." Each reimplementation 30 
results in a redesign, recompile, and retest of the changed 
code. 

FIG. 107 illustrates an object-based system 10700 with a 
frequently changing object model 10702 communicating via 
Stream-Based Communication 10704. 

FIG. 107 depicts a constandy dianging system. Initially, 
the object-based system 10700 is designed to send Poodle 
objects through a stream to a non-object system 10702. As 
time passes, the system requirements change. Now, the 
object-based 10700 system must send German Shepherd 
objects through a stream to the non-object system 10702. If 
the "shared format" for converting dog objects to raw data 
is inflexible, this will break the system. 

In cases like this, it would be better to implement a 
communication mechanic or "^ared format" that can 45 
better handle changes to the systems. 

Therefore, use a Self-Describing Stream and create a 
stream that contains message data AND descriptive meta- 
data. Then use a message language to read the formatting 
information and meta-data off of the stream. 

FIG. 108 illustrates a stream-based message that contains 
both message data 10800 and descriptive meta-data 10802. 

FIG. 108 depicts a message sent using a Self -Describing 
Stream. The first 30 bytes contain descriptive meta-data 
10802. This meta-data 10802 describes the formatting of the 
"real" data 10800 in the remainder of the message. It 
describes the data type, attribute names, location in the 
message, etc. of the "real" data 10800 in the message. The 
remaining 70 bytes are the "real" data 10800 transmitted 
between the two systems. 

Additionally, each system must implement a message 
language. The message language defines the rules for writ- 
ing and interpreting the descriptive meta-data. It describes 
how the meta-data is parametarised and embedded in the 
message. 

These Self-Describing messages usually contain three 
distiiKt sections: a generic header, an attribute descriptors 
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section, and a data section. The header portion contains 
generic information about the message. It contains such 
information as the type of object, the number of attributes 
descriptors, the target environments, etc. The attribute 
descriptors section contains a series of attribute descriptors 
that define the various data elements of the information. The 
number of these attribute descriptors is usually defined in the 
header section. The last section contains only data. 

FIG. 109 illustrates the manner in which a message 
language defines how to parameterise the meU-data 10900 
and put it on the stream. 
Benefits 

Greater Flexibility. Because the information about the 
structure of the data has been parameterised and stored 
as additional data within the message, changes to the 
data structure would have no effect on this interface 
mechanism. This means the interface mechanisms will 
not need to be re-designed/re-built/re-tested/re- 
deployed, etc for each change in meta-data. 
Interfacing systems are better de-coupled. Because the 
message fonnat is embedded in the actual stream, this 
format does not need to be stored or kept in synch 
across different systems. It can be "discovered" at 
run-time when the interface is invoked. 
For object-based systems, the implementation is quite 
straightforward. Simply make each object responsible for 
implementing streaming behaviors based on the format and 
message language. Each object should know how to get and 
parse its attribute values onto a stream as string values 
(streamOn) and each object class ^ould know how to parse 
attributes off of a stream and put these values into a new 
instance of the object (streamOflP). 

Below is an example of a Self-Describing stream. It is 
used to stream an object's information fi"om an object-based 
system to a non-c^ject system. 

FIG. HO illustrates a Customer object 11000 in an object- 
based system 11002 streaming itself into a stream 11004, the 
stream 11004 being sent to a non-object system 11006, this 
stream 11004 being read and the data inserted into a rela- 
tional database 11008. The steps illustrated in FIG. HO will 
now be set forth. 

1. The CustomerObject with attributes name, sex, and age 
has a method "streamOn: aStream." It is invoked with 
an empty stream as the argument 'aStream*. The Cus- 
tomerObject "streamOn:" method goes through each of 
the object's attributes and parses each value as a string 
onto the stream. 

In the Java pseudo-code below, the message language 
defines the format of the header, the format of the 
attribute descriptors, and the delimiter used in the 
parsing. 



Note: Assume that ''&sScriDg( )" converts the rcodver to a string and that 
'*pad¥^Spaces( )"pads the string with spaces and makes the string the 
length specified. 

/*• Stream my attrfljute vahies on aStream ••/ 
public void streamOn (OutputStream aStieam) 
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{ 



// CREATE THE HEADER 

aStreanuwriteC CUSTOMER //This is a customer object 

aStream.write('003'); // with three attributes 

aStream-writef 001*); // this is the format version 

// DESCRIBE EACH AITRffiiriE 

aStrcam.write(Stream.Dclimiter); 

aStreanuwrite('NAME '); 

aStrcam.writc('STG 
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aStream.writcCOlO'); 
aStream.write(StrcanLDeUimter); 
aStream-writeCSEX '); 
aStream.writeCSIXj 
aStream.writcCOO?'); 
aSticam.write(Strcain.DeLiniiter); 
aStrcam.writc('AGE '); 
aStreaIn.write('^^UM *); 
aStrcam.writc(*003'); 

// WRTTE OUT THE ATTRIBUTE VALUES AS DATA 
aStrcain.wTitc(Sticam.DeUmiter); 

aStrcam.writc(tliis.gctName( ),asString( ).padWithSpaccs(30)); 
aStrcanLwritc(this.gctSat( ).asStriiig( ).padWithSpaccs(7)); 
aStreain.writc(this.gctAge( )^truig( ).padM^Spaccs(3)]f, 



*** FIND WHAT BYTE THE DATA STARTS AT AND SET THE 
INDEX **** 

MOVE (IT-ATTRIBUTE-DESCRIFTOR-SIZE » WS-HEADER-NUM- 

OF-ATTRIBUTES) 

TOWS-INDEX. 

*** PARSE THE APPROPRIATE OBJECT STRUCTURE OFF OF 
*** THE STREAM 

IF WS-HEADER-OBJECT-TYPE EQUALS "CUSTOMER" THEN 
PERFORM lOOO-PARSE-CUSIOMER-STREAM THRU 
lOOO-PARSE-CUSTOMER-SniEAM-END. 

ELSE IF WS-HEADER-OBJECT-TYPE EQUALS "EMPLOYEE" 

THEN 



ELSE IF 
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2. The stream is then put into a message communication 
mechani^n like MQSeries or MessageQ and sent to the 
non-object system. 

3. Once at the non-object system, interface code reads the 
stream, parses the values off, converts and moves the 
values into a copybook with the appropriate structure, 
and saves the information in relational database. A 
pseudo-COBOL example is listed below. In reality, this 
interface code would be more dynamic than depicted in 
this example. 



DAIA DIVISION. 
FD HLE-STREAM-IN 

RECORD CONTAINS 100 CHARACTERS 



20 



WORKING^TORAGE SECHON. 

01 WS-HLE-STREAM-IN 

Ol WS-SHARED-PORMAT-HEARDER 

03 WS-HEADER-OBJECT-TYPE 

03 WS-HEADER-NUM-OF- 

ArnUBUTES 

03 WS-HEADER-VERSION-OF- 
FORMAT 

Ol WS-SHARED-FORMAT- 
ATTOIBUTE 

03 WS-ATTRIBUTE-NAME 
03 WS-ATTRIBUTE-TYPE 
03 WS-ATTRIBUTE-SIZE 
Ol TEMP- VARIABLES 
03 WS-INDEX 

01 WS-CUSrOMER 
03 WS-NAME 
03 WS-SEX 
03 WS-AGE 



PIC X(100). 

PIC X(10). 
PIC X(7). 

PIC 999. 



PIC X(5). 
PIC X(5). 
PIC 999. 

PIC 9999. 



PIC X(10). 
PIC X(7). 
PIC 999. 

PDC 99 VALUE 20. 



88 LT-HEADER-SIZE 

88 IT-ATTRIBUTE-DESCRIPTOR-SIZE PDC X(l) VALUE 14. 

88 LT-DEUMINATOR PDC X(l) VALUE ^l". 

88 LT-STRING PDC X(l) VALUE -SHT. 

88 IT-NUMBER PDC X(l) VALUE "NUM". 

PROCEDURE DIVISION. 

OPEN THE FILE STREAM AND READ FT INTO THE 
TEMPORARY *** 

*** VARIABLE WS^FILE-STREAM-IN **• 
OPEN FTLE-STREAM-IN. 

READ FILE-STREAM-IN INTO WS-FILE-STREAM-IN 

AT-END CLOSE FTLE-STREAM-IN 

END-READ. 

MOVE THE HEADER INFORMAnON INTO THE HEADER 
COPYBCK>K***» 

MOVE (WS-FILE-STREAM-IN FROM ZERO TO LT-HEADER-SIZE) 
TO WS-SHARED-FORMAT-HEADER. 



ELSE 

*♦* END THE PROGRAM 
RUN-STOP. 
END-IR 

lOOO-PARSE-CUSTOMER-STREAM. 

*♦* READ WHICH VARIABLE FT IS AND POPULATE THE 
CORRECT 
•** VARIABLES 

IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX +5)) - 

"NAME" 

THEN 

MOVE WS-INDEX TO SIART-INDEX. 
25 *•* HND THE DELIMINATOR AFTER THE NAME STRING AND 



*** MOVE THE NAME VALUE INTO THE SEX VARIABLE 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-FILE-STREAM-IN AT INDEX) = IT- 
DELtMINATOR 
END-PERFORM. 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX) TO WS-SEX. 

PERFORM lOOO-PARSE-CUSTOMER-STREAM 
THRU lOOOPARSE-CUSTOMER^TREAM-END. 
ELSE IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX + 
5)) --SEX" 
THEN 

♦** FIND THE DEUMINATOR AFTER THE SEX STRING AND 
MOVE **• 

**• THE SEX VALUE INTO THE SEX VARIABLE •** 

MOVE WS-INDEX TO SDUIT-INDEX. 

PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-FILE-STREAM-IN AT WS-INDEX) = LT- 
DEUMINATOR 
END-PERFORM 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX)TO WS5EX 

PERFORM lOOO-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAA^END. 
ELSE IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX -i- 
5)) - -AGE" 
THEN 

***FIND THE DEUMINATOR AFTER THE SEX STRING AND 
MOVE*** 

***THE SEX VALUE INTO THE SEX VARIABLE *** 

MOVE WS-INDEX TO SIART-INDEX. 

PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-FILEnSTREAM-IN AT WS-INDEX) - LT- 
DEUMINATOR 
END-PERFORM 

MOVE (WS-FILE-STREAM FROM START-INDEX 
TO WS-INDEX)rrO WS-SEX 

PERFORM lOOO-PARSE-CUSnOMER-STREAM 
THRU 1000-PARSE<XfSrOMER-STREAM-END. 
ELSE IF (WS-FILE-STREM FROM WS-INDEX TO (WS-INDEX 
+S)) «=. "AGE" 
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THEN 

*•* FIND THE DElIMINArOR AFTER THE AGE STRING AND •** 
* •* MOVE THE AGE VALUE INTO THE AGE VARIABLE *** 5 
MOVE INDEX TO STAKT-INDEX. 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BYl 

UNTIL (WS-HLE-STREAM-IN AT WS-INDEX) = LT- 10 
DEUMINATOR 
END-PERFORM 

MOVE (WS-FILE-SFREAM FROM SIART-INDEX 
TO WS-INDEX) TO WS-AGE 

PERFORM lOOO-PARSE-CUSTOMER-SnrREAM 
THRU lOOO-PARSE-CUSTOMERnSTREAM-END. 
ELSE 

PERFORM 2000-SAVE-CUSrrOMER THRU 
2000-SAVE-aJSTOMER-END. 
END-IF. 

lOOO-PARSE-CUSrOMER-STREAM-EXTT 
2000-SAVE-CUSTOMER. 

•** CALL A SQL MODULE TO SAVE THIS INFORMAHON IN ^ 
THE 

RELATIONAL DAIABASE 
CALL "SAVE-CUSTOMER-IN-DArABASE" USING WS- 
CUSTOMER 

2000-SAVE-CUSrrOMER-END. 25 



Cbnversely, a stream could be created by a non-object 
system or another object system, populated with customer 
informatioD, and sent to one's object-based system. Once in 
the object-based system, the CustomerObject could use a ^ 
"streamOfif: aSteam" method, instanciate a CustomerObject, 
and populate it with the appropriate attribute values. 
Collaborations 

Stream-based Conununication. This is the parent pattern 
to the Self-Describing Stream pattern. In this pattern, infor- 35 
mation is transmitted using a simple stream and a shared, 
generic format The Self-Describing Stream is a more spe- 
cific implementation of Stream-Based Communication. 

Bridge (from the Gamma book Design Patterns) describes 
a way to de-couple an abstraction from its implementation 40 
so that the two can vary independently. Hie Bridge pattern 
is often used to define collaborations between a business 
object and a format object while decoupling the business 
object from its specific stream format. 

Abstract Factory (from the Gamma book Design Patterns) 
is a pattern for creating families of related classes. This 
could be used with the Bridge pattern to retrieve the format 
dynamically based on non-static information. 
Alternatives 

Fixed Format Stream — ^This pattern is a specific variation 
of Stream-Based oonununication where the messaging for- 
mat is defined and stored on both the sending and receiving 
systems. 

Downloadable Format Stream — TTiis pattern is a specific 
implementation of Stream-Based communication where the 
messaging format is stored at a central location and is 55 
downloaded by the communicating parties when needed. 
Stream-based Communication 

FIG. Ill illustrates a flowchart for a method 11100 for 
providing a stream-based communication system. A shared 
format is defined on interface code in operation 11102 for a 60 
sending system and a receiving system. A message to be sent 
from the sending system to the receiving system is translated 
based on the shared format in operation 11104. The message 
is sent frxtm the sending system and received by the receiv- 
ing system in operations 11106 and 11108. The message 65 
received by the receiving system is translated based on the 
shared format in operation 11110. 
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As an option, information in the translated message 
received by the receiving system may be stored in a rela- 
tional database. As another option, the shared format may be 
based on an order of attributes in the message. 

In one version, one of the systems may be an object-based 
system and one of the systems may be a non-object-based 
system. In another version, both of the systems may be 
object-based systems. In a third version, both of the systems 
may be non-object-based systems. 

In order to successfully transmit a formatted message, 
both the sending and receiving systems must understand the 
format and structure of the transmitted information. Some 
communications mediums, however, do not inherently trans- 
mit the formatting information with the data. How can 
information be easily commimicated between systems when 
the conmiunication mechanism does not inherently convey 
data stmcture or other meta-data information? 

For two systems to successfully communicate, they must 
understand the structure of the data they are passing. The 
sending system needs to convert standard programming 
constructs (objects, structure, strings etc.) into bytes of data 
that can be transmitted along a network. The receiving 
system needs to receive the bytes of data on a wire and 
reconstitute it back into objects, structure, strings etc. 

Many communication mechanisms inherently provide 
this functionality to a software developer. CORBA and 
DCOM are two examples of this type of middleware. Using 
CORBA, one system can send a structure of information to 
another system. CORBA will convert the structure into a 
network appropriate format, transmit it across the network 
and reformat it on the receiving end. 

Other types of middleware, however, do not provide this 
fiill range of functionality. Lower level conununication 
protocols like TCP and UDP as well as higher-level proto- 
cols like HTTP and telnet do not provide support for sending 
data stmctures. 

Additionally, popular message queuing software (IBM'S 
MQSeries and BEA MessageQ) and many custom commu- 
nications mechanisms are laddng support for transmitting 
structured data across the network. 

These communication protocols do not inherently convey 
meta-data information. 'Meta'-data is information about the 
data. Meta-data could desoibe the data structure (senders 
address in bytes 1-10, receivers address in bytes 11-20, data 
in 21-100, etc.), data types, etc. 

When the highest-level common communication protocol 
between two systems cannot convey this meta-data 
information, an alternative communication mechanism is 
needed. 

FIG. 112 illustrates how systems 11200, 11202 of the 
present invention communicate over a conmiunication 
mechanism 11204 that caimot inherently convey meta-data 
information. 

How can they exchange structured data? 

In object-based systems, issues with conveying meta-data 
are even more prevalent. Object-based systems often need to 
transfer object information across non-object communica- 
tion mechanisms (e.g. DCE, . . . ) or to non-object systems. 
Because neither non-object communication mechanisms nor 
the non-object systems understand the notion of objects, 
how can the structure of the objects be meaningfully con- 
veyed? 

FIG. 113 is an illustration of an object-based system 
11300 communicating with a non-object system 11302 using 
a communication mechanism 11304 that cannot convey 
meta-data information. 

How can they exchange structured data? 

Therefore, use Stream-based Communication to transit 
information between systems. Stream the data between the 
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two systems and use a generic format to relay the infonna- 
tioD and its associated meta-data between the systems. 

A stream is simply a buffer that data is "written to" and 
"read from" in discrete quantities. The size of the buffer is 
predetermined and can be very small (i.e. one byte in length) 
or very large (i.e. a page). The buffer can't hold objects or 
structures, but just raw data. Buffers are quite dumb and 
don't understand anything about their raw data. Thus, it does 
not have meta data for the information in the buffer. 

The "shared format" provides the meta-data information 
needed to interpret the raw data in the buffer. This shared 
format is like a secret decoder ring for systems sending and 
receiving messages. The sending system uses the decoder 
ring to convert objects, structures, etc. into raw data on a 
stream. The receiving system uses another decoder ring to 
reconstitute the raw data back into objects or structures. If 
objects aren't supported, the raw data is converted into a 
comparable format for use by the receiving system. 

FIG. 114 depicts an example of Stream Based Commu- 
nication with two disparate systems 11400, 11402 commu- 
nicating via stream-based communication 11404. 

In FIG. 114, the object-based system 11400uses a ^ared 
format (decoder ring) to convert an object into raw data. The 
raw data is then copied onto the stream. The stream then 
delivers the data to the Non-Object system 11402. The 
Non-Object system 11402 reads the raw data and reconsti- 
tutes the data using its shared format. 

In this example, the sending system is sending objects 
while the receiving system doesn't understand objects. Thus, 
the receiving system can only convert the raw data into a 
data equivalent of the object sent. 
Benefits 

Maintainability. When using this pattern, a shared, generic 
format is used to interpret the data. As a result, the two 
systems are de-coupled and less dependent upon each 
other. As long as the format remains unchanged, 
changes to the internal implementation of either system 
will not affect the other system. Maintenance of 
decoupled systems is easier. 
Batch Compatible. Strings of data can be concatenated 
and tran^nitted as a group. This enables batch mes- 
saging (e.g. Request Batcher) and processing. 
Enables lightweight Persistence. Stream-based commu- 
nication can be used to interface with a lightweight 
persistence mechanic. Objects, structures^ etc. can be 
can be converted to raw data and streamed to a flat file 
for saving. At a future time, the file can be opened, the 
raw data can be streamed out of the file and reconsti- 
tuted into fill! blown objects or structures. 
The implementation of Stream Based Communication is 
very straightforward. Simply define interface code on the 
sending system that creates a stream and parses the data onto 
this stream using a format shared by the both the sending and 
receiving systems. On the receiving system, define interface 
code that reads the stream and, using the same shared 
format, parses the data off of the stream and into a data 
structure compatible with the receiving system. 

The specific implementation of the formats can be, and 
most likely will be, different from system to system but the 
actual format must be shared and should be generic between 
systems. Shared so that the information is accurately relayed 
and generic to keep the systems as de-coupled as possible by 
not exposing any implementation details of either system in 
the fonmat. Further, this shared format can be implemented 
in a variety of places depending upon the specific require- 
ments of the interface. 

For object-based systems, make each object responsible 
for implementing streaming behaviors that use this shared 
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format. Each object should use the format as a map to parse 
the attribute values onto a stream (streamOn). Conversely, 
each object class should use the format as a map to parse its 
attribute values off of a stream and put them into a newly 
instantiated instarKe of the object (streamOfl^. 

In the example below, an object within an object-based 
system uses stream-based communication to stream its 
attribute values onto a stream. Then a communication 
mechanism transports the stream to a non-object system, and 
a non-object system reads the information off of the stream 
and inserts it into its relational database. 

FIG. 115 is an illustration of a Customer object 11500 in 
an object-based system 11502 streaming itself into a stream 
11504, the stream 11504 being sent to a non-object system 
11506, this stream 11504 being read and the information is 
inserted into a relational database 11508. 

1. The CustomerObject with attributes name, sex, and age 
has a method "streamOn: aStream." It is invoked with 
an empty stream as the argument 'aStream'. The Cus- 
tomerObject "streamOn:" method goes through each of 
the object's attributes and parses each values as a string 
onto the stream. 

The fixed format contract here is embodied in the order 
that this method parses the attributes onto the stream. 
A pseudo-code example in Java is the foUovmg: 
Note-Assume that "asString( y converts the receiver 
to a string and that "padWithSpaces( )" pads the 
string with spaces and makes the string the length 
specified. 



/•* Stream my attribute values on aStream 
public void streamOn (OulputStrcam aStrcam) 

aStrcam.write(this.getName( ).asString( >padWtliSpaces(10)); 
aStream.write(this.getSex( ).asString( ).padWtliSpaces(7)); 
aStream.writc(this.getAgc( ).asStting( ).padWithSpaces(3);fc 



. Hie stream is then put into a message corrmiunication 
mechanism like MQSeries or MessageQ and sent to the 
non-object system. 

. Once at the non-object system, interface code reads 
through the stream, parses the values off of the stream, 
converts them to the appropriate types if required, and 
puts them in a copybook with the appropriate structure. 
In this example, the fixed format contract is embodied 
in the structure and type of the WS-SHARED- 
FORMAT-CUSTOMER working-storage copybook. 
Refer to the pseudo-COBOL example below. 

DATA DIVISION. 



65 



FD FTLE-STREAM-IN 

RECORD CONTAINS 20 CHARACTERS 

WORKING-SrORAGE SECnON. 

♦* • THIS COPYBOOK CONTAINS THE SHARED FORMAT OF 
THE 

*•* CUSTOMER IN THE DATA STRUCTURE AND DAIA TYPES 

01 WS-SHARED-FORMAT-CUSTOMER 

03 WS-SHARED-FORMAT-NAME PIC X(10). 

03 WS-SHARED-FORMAT-SEX PIC X(7). 

03 WS-SHARED-FORMAT-AGE PIC 999. 

♦** THIS COPYBOOK IS THIS SYSTEMS VIEW OF A CUSTOMER 

Ol WS-CUSTOMER 
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03 WS-NAME 
03 WS-AGE 
03 WS-SEX 

PROCEDURE DIVISION. 



PIC X(10), 
PIC 999. 
PIC X(10). 



OPEN THE HLE STREAM AND PUT THE CONTENTS IN THE 
WS-SHARED-FORMAT-CUSrOMER COPYBOOK. 
OPEN FTLE-STREAM-IN 

READ FILE-STREAM-IN INTO WS-SHARED-PORMAT- 
CUSTOMER 

AT-END CLOSE FTLE-STREAM-IN 
END-READ, 

MOVE THE VALUES INTO FROM THE SHARED FORMAT 
INTO 

THE WS-CUSTOMER VARIABLES. 
MOVE WS-SHARED-FORMAT-SEX TO WS-SEX- 
MOVE WS-SHARED-FORMAT-AGE TO WS-AGE. 
MOVE WS^HARED-FORMAT-NAME TO WS-NAME. 

*♦* CALL A SQL MODULE TO SAVE THIS INFORMAHON IN 
THE 

*** RELATIONAL DAIABASE 

CALL "SAVE-CUSIOMER-IN-DATABASE" USING WS- 
CUSTOMER. 

STOP-RUN. 



Conversely, a stream could be created by a non-object 
system (or another object-based system for that matter) 
and sent to one's object-based system. In this case, 
CustomerObject could use a "streamOff: aStream" 
method and instanciate a new instance of a aCustomer- 
Object and populate it with the appropriate attribute 
values. 

Again, there are several variations of this pattern depend- 
ing upon what the specific requirements are. Some of these 
variations are further explained in the children patterns. 
Refer to Fixed Format Stream, Downloadable Format 
Stream, and Self-describing Format Stream. 
Collaborations 

Fixed Format Stream — This child pattern is a specific 
variation of Stream-Based communication where the mes- 
saging format is defined and stored on both the sending and 
receiving systems. 

Downloadable Format Stream — This child pattern is a 
specific variation of Stream-Based communication where 
the messaging format is stored at a central location and is 
downloaded by the communicating parties when needed. 

Self-Describing Stream. This child pattern is a specific 
variation of Stream-Based communication where the mes- 
saging format is parameterised and stored on the stream. A 
message language is used to read and write the format of the 
message from the stream. 

Stmcture Based Communication — ^Tliis pattern uses a 
Fixed Format Stream to transmit data structure between 
systems. It is often used to obtain data firom a Server for 
display in a Client UI. 

Bridge (from the Gamma book Design Patterns) 
describes a way to de-couple an abstraction from its imple- 
mentation so that the two can vary independently. The 
Bridge pattern is often used to define collaborations between 
a btisiness object and a format object while decoupling the 
business object from its specific stream format 

Abstract Factory (from the Gamma book Design 
Patterns) is a pattern for creating famihes of related classes. 
This could be used with the Bridge pattern to retrieve the 
format dynamically based on non-static information. 
Structure-based Communication 



FIG. 116 illustrates a flowchart for a method 11600 for 
eflSciently retrieving data. A total amount of data required for 
an application executed by a client is determined in opera- 
tion 11602. In a single call, the total amount of data from a 
5 server is requested over a network in operation 11604. AU of 
the data is bimdled in operation 11606 into a data structure 
by the server in response to the single call. In operations 
11608 and 11610, the bundled data structure is sent to the 
client over the network and the data of the data structure is 
cached on the client. The cached data of the data structure is 
used as needed during execution of the application on the 
client in operation 11612. 

The data stmcture may be bundled on the server by a 
business object. In addition, the business object may be 
instantiated by an action of the client. Also, the network may 
1^ be at least one of a local area network and a wide area 
network. As a further option, the request may be adminis- 
tered by a proxy component. Further, the data structure may 
contain no logic. 

In a client server application, the client communicates 
with a server over a network. Depending upon the speed of 
the netwodc and the number calls across the network, an 
application can experience performance problems. How can 
a client update a server while minimizing the network traffic 
and maintaining an acceptable level of system performance? 

Acceptable system performance is an important attribute 
of every appUcation. When creating a client-server 
application, the perfonnance of the network must be con- 
sidered during the design and development of an applica- 
tion. The speed at which data can be transmitted across the 
Local Area Network or Wide Area Network, can make or 
break a client-server application. 

In a typical three-tiered client-server application, the 
business objects are maintained away from the users (Client) 
on separate Server machines. Whenever a user needs the 
expertise of a business object, the user must send a request 
across the network to the Server machine. 

FIG. 117 illustrates the manner in which a client 11700 
requests information from server objects 11702 via a net- 
work 11704. 

Depending upon the size of the message and the speed of 
the network, this could take a long time. This is a reality of 
three-tiered client-server applications. 

When a client-server application is introduced to the 
world of distributed objects, the network can become an 
even larger botdeneck. In a pure distributed object approach, 
the client is passed an object reference to a biisiness object 
on a server machine. The client then accesses the specific 
business object over the network as if it resided on its local 
machine. Using this "pure" distributed object approach, the 
application's calling pattern begins to look like the sche- 
matic of FIG. 118. 

FIG. 118 illustrates the method of the present invention in 
which a client 11800 requests attributes from a server object 
11802 via a network 11804. 

This is an excellent programming model that frees the 
developer to access local and remote (Ejects in the same 
fashion. Unfortunately, it makes it easier for the application 
developer to forget about the physical realities of the net- 
work. A network call is always slower than a call within a 
single machine. Ignoring this reality may result in an unac- 
ceptably slow application. 

On a very fast LAN where the number of network calls is 
small, this calling pattem may be acceptable. On a slower 
LAN, any WAN or when the number of network calls is 
large, this pattem wiU yield unacceptable network perfor- 
mance. Something must be done to maintain an acceptable 
level of system response for the users. 
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FIG. 119 ilustrates the traDsmitting of all data ia a Data 
Structure 11900 from a clieat 11902 to a server 11904 and 
visa-versa. As shown, to maximize the performance on the 
client, it is best to bundle all the necessary data into a single 
data stmcture that can be transmitted as a structure across the 
network. 

The Client would first determine the sum total of every- 
thing it will need from the business object on the Server 
machine. The Client makes a request for all of this data from 
the bxisiness object. The business object bundles all the data 
into a data structure and returns it to the client. The Client 
will cache this data (using the Caching Proxy pattern) on its 
local client machine and use it as needed. 
Benefits 

Better System Performance — This pattern will improve 
the performance of an application by reducing the 
network traflSc between the client and the server. The 
client makes one network request to retrieve all of the 
data from the server. Regardless of the number of 
displayable attributes the application will only make 
one network send. 
Without this pattern, the client could make a network send 
for every attribute retrieval. If the user wants to retrieve 
a customer's name, address and phone number, that 
could result in three network requests (one for each 
attribute). Without this pattern, the network traffic can 
become prohibitive and the performance would suffer. 
Structure Based Communication assumes a client needs 
information from an object that exists on a server. Thus, this 
pattern assumes the existence of an "interesting" object on 
the server machine. 

Even though the "finding" and "instantiating" of a server 
object isn't part of this pattern, it does establish context and 
sets the stage for the pattern. As a result, a message trace 
diagram for finding and instantiating a particular object 
instance is shown below. This will set the stage for the 
implementation of the Structure Based Communication pat- 
tern. 

FIG. 120 illustrates the method in which a client 12000 
finds and instantiates a Customer Object from a customer 
component 12002. The various steps shown in FIG. 120 will 
now be set forth. 
Collaborations 

1. The client instantiates a Proxy (Customer Component 
Proxy) to the Customer Component. The Client then asks 
the Proxy for Customer Jimbo Jones. 

2. The Customer Component Proxy forwards the request 
across the network to the Customer Component. 

3. The Customer Component requests the information for 
Jimbo Jones from the database. 

4. The Database returns the data associated with customer 
Jimbo Jones. 

5. The Customer Server Component instantiates a customer 
object using the Jimbo Jones data from the database. 

6. The Customer Server Component returns a remote object 
reference to the "Jimbo Jones" object running on the 
Server. 

7. The aient creates a proxy to the "Jimbo Jones" object 
using the remote object reference. 

Now that a customer object (Jimbo Jones) exists on the 
server component. Structure Based Communication can be 
used to pass the needed data from the server to the client. 

FIG. 121 ilustrates a Stmcture Based Communication that 
builds upon the method of FIG. 120 and depicts the flow of 
control during Structure Based Communication. The various 
steps shown in FIG. 121 will now be set forth. 
Collaborations 



10 



15 



20 



30 



35 



8. The Client asks the Customer Proxy for the data associ- 
ated with the Jimbo Jones object 

9. The Customer Proxy forwards the request across the 
network to the Customer Component. 

10. The Jimbo Jones object creates a data structure and 
populates it with its data. 

11. The Data Structure is passed across the network to the 
Customer Proxy on the Client. 

12. The Customer Proxy forwards the data structure con- 
taining Jimbo Jones' data to the Client component. 

Participants 

Client — The "client" for the transaction. This could be a 
User Interface that displays customer data for viewing 
by a Customer Service Representative. 
Network — ^A LAN or WAN network that connects the 

Client with the Customer Component. 
Customer Component — ^A server component that encap- 
sulates the data for all of the customers in a system. 
Customer Component Proxy — A proxy to the Customer 
Component Any request it receives, it forwards across 
the network to the Customer Component 
Customer Proxy — A proxy to the Jimbo Jones Customer 
Object Any request it receives, it forwards across the 
network to the Jimbo Jones Customer Object. 
ACustomerStructure — A data structure. It contains the 

data (but no methods) from the Jimbo Jones object. 
Database — ^Any relational database. 
Jimbo Jones Object — An object that represents the Jimbo 
Jones customer. This object contains Jimbo Jones' data 
and methods associated customer methods. 
Sample Java Code 

The following java example accompanies the previous 
message trace diagrams. The java code follows the same 
scenario as the message trace diagrams, but it has been 
simplified in some areas. 

The following snippet of code defines the data structure 
used to pass customer information. 



40 



45 



50 



60 



65 



public CustoincfStmctme( 
String firstName, 
String lastName, 
short streetNumbcr, 
String street. 
String city. 
String state. 
String zipCodc) 



The following block of code is the "main" routine for the 
Client. Even though all distributed calls are made through a 
proxy, the proxy code is not shown in this example. The two 
proxy classes encapsulate the details associated with dis- 
tributed network calls. 



// Client side code here. 
Main() 
{ 



// Create a Proxy to the Customer Conqwnent. 
CustomerComponentProxy aCustomeiCfoniponeiitPrazy - 

new CustomeiComponentPrDzy( ); 
// Get a Proxy to the Jimbo Jones Customer 
// object 

CustomcrProxy aCustomerPioxy = 

aCastomeiComponentPraxy.getCUstomcrCJimbo Jones"); 
// Get Customer data &om the Customer Server 
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-continued 



// Gompoiient(Call across the network) 
CustomeiStmcture aOistomerStructure = 

aCustoinerPioxy.getCustoinerAsStnicture( ); 
// Use the Customer data received in the 
// structure. For Example, display the data 
// structure data (aCustomciStructure) in a UI. 



The following code is a sample Customer Server Com- 
ponent. The Customer Server Component is used to retrieve 
the data associated with customer Jimbo Jones from the 
database. It also instantiates a customer object using the data 
retrieved finom the database. 



// Customer Con^onent Code here 
public dass OistomerComponent 

// Put the data associated with a Customer Object 
// into a data Structure. This data structure 
// will be sent across the network to a dient 
public Oistomer getCustQmer(String aCustomerName) 



{ 



// Find the Customer in the database 



// Instantiate the Customer Object 
Customer aCustomer = new Customcr(„ 



// Return a "remote object reference" to the 
// Jimbo Jones Customer objecL 
return (aCustomer); 



} 
} 

Finally, this is the code for the Jimbo Joites Customer object 
// Customer object code here 
public class Customer 

{ 

// Put the data associated with a Customer Object 
// into a data Structure. This data structure 
// will be sent across the netwoik to a dient 
public CustomerStructure getQistomerAsStructure( ) 

CustomerStructure aCustomerStructure » new 
CustomerStructure( ); 

aCustomerStmctuie.firstNan:w » this.getFirstNamc( ); 
aCustomerStmctureJastName = this.getLastName( ); 
aCustomerStmcture JtreetNumber = this.getStreetNumber( ); 
aCustomerStmctuie^treet » this.get&ieet( ); 
aCustomerStmcture.city = this.^tCity( ); 
aCustomerStmctuic^tate » this.getState( ); 
aCustomerStiuctuie JiqiCode =■ tihis.getZipCode( ); 
return aOistomerStructure; 

} 

// Getters and Setters for aU attributes 
// (code not shown here) 



} 

Note: The "Main" code exan^le above detains a Proxy to customer 
"Jimbo Jones" and then a Structure of data through the pn>zy. Hie code 
was written for ease of understanding, but causes two calls across the 
network In reality, it is prefened to perform both functions using one 
network call. LiTniting the number of network calls will improve system 
peifonnance. Hie lecommended code might look something like this: 
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// Create a Proxy to the Customer Cbnqranent 

// (same as above) 
^ CustomeiComponentProxy aCustomerComponentProzy = new 

CustomeK^mponentProxy( ); 
// Get a Proxy to the Jimbo Jones Customer . 
// t*ject 
// AND 

// customer data at the sams time. 
10 CostomerProxy aOistomerProxy; 

CustomerStructure aCustomerStructure = 

aQistomeiComponentPraxy.getQistomerData('*Jimbo Jones", 
aCUstomcrProxy); 

Collaborations 

Proxy — This pattern is documented in the book "Design 
Patterns" by Gamma, Helm, Johnson and Vlissides. The 
proxy pattern is often used to communicate with server 
components in a distnbuted environment. The Proxy pattern 
is often used to retrieve data structures from a server 
component. 

Cached Proxy— This pattern is documented in "The 
Proxy Design Pattem Revisited" section of the Pattern 
Languages of Programming Design 2 book. A Cached Proxy 
caches data locally on the client. Structure Based Commu- 
nication uses and builds upon this pattem. 

Globally Addressable Interface — ^This pattem often works 
in conjunction with Stmcture Based Communication. 
Oftentimes^ a Globally Addressable Interface is used to 
obtain Structures of data for display on a Client. 

Locally Addressable Interface — This pattern can also be 
used in conjunction with Structure Based Communication. 
After establL^ing a relationship with an LAI, a client may 
obtain data from the Server object using Structure Based 
Communication. 
Alternatives 

Distributed Objects— The "pure" distributed object 
approadi is an alternative to Structure Based Communica- 
tion. Using this pattem, individual objects are queried for 
each piece of information needed by a cUent. 

40 Presentation Services (1000) 

Presentation Services enable an application to manage the 
humanHX)mputer interface. This includes capturing user 
actions and generating resulting events, presenting data to 
the user, and assisting in the management of the dialog flow 

45 of processing. The Presentation Services forward on the user 
requests to business logic on some server. Typically, Pre- 
sentation Services are only required by cHent workstations. 

In addition to Presentation Services on the client, some 
business logic wiU usually reside on the client as well to aid 

50 the Presentation Services. Even on thin clients some sort of 
validation logic is usually included with the Presentation 
Services. A quick review of the Gartner Group's five styles 
of client/server computing help to illustrate this. 
FIG. 122 shows the Gartner Group's Five Styles of 

55 Client/Server Computing 12200. 

The way that Presentation Services interact with client- 
side business logic is very important to the overall scalabil- 
ity and maintainabOity of the application. An apphcation's 
business logic is expected to be highly reusable, even on the 

60 client. If business logic is coupled with the Presentation 
Services too tightly, it wiU be very diflScult to separate and 
reuse the business logic if the Presentation Services ever 
need to be altered (not an uncommon occurrence). 
The patterns in this section help to guide application 

65 architects on strong, proven techniques to safely integrate 
client-side business logic with an application's Presentation 
Services. The Activity pattem lays the groundwork for 
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sqjarating the Presentation Services and business logic on Often these user interfaces will be changed over time to 

the client by assigning non-presentation logic to a type of fit user's changing needs. While the tasks completed by the 

object called an Activity. The ^^ew Configurer pattern helps user may not change, the interface to complete those tasks 

to assign new views with their appropriate Activity. Finally, will need to. Windows users will want to move to the Web. 

the User Interface Validator pattern describes how to imple- 5 Web users will want to move to handheld devices. Tte 

ment customizable, extendable validation logic on a user presentation code should be able to be changed without 

interface. causing a rewrite of the business logic on the client. 

Activity Therefore, bundle business logic executed on the client 

FIG. 123 illustrates a flowchart for a method 12300 for separate firom the presentation logic. This new type of class 

providing an activity module. A server and a presentation is an Activity, 

interface of a client are interfaced to permit the receipt of An Activity is responsible for: 

requests for service from the presentation interface of the managing client logical units of woric 

cHent in operations Um arid 12304. A portion of the maintaining client representation of a business model 

requests are handled on the chent m operation 12306. In i-a ^ i** 1 • . ^ / 1 • 

^ i'>^Ao A i-iain *u lu validation across muluple mterfaces (complex business 

operations 12308 and 12310, another portion of the requests lode) v 

are forwarded to the server for further handling purposes and j . «. 

changes are efl^ected in the presentation interface ^^''^^ exception handling 

A pluraUty of presentation interfaces may be interfaced. commumcaUon with server and other services 

Optionally, a model may be interfaced for management creating other Activities 

purposes. Wth such an option, the model may further triggering events intended to be "caught" and acted on by 

include a proxy. As another option, errors and exceptions 20 presentation logic 

may also be handled. As a third option, events intended to be An Activity resides between the actual user interface and 

received may be triggered by the presentation interface. the business model and server components as shown in the 

Many client/server applications maintain some amount of Entity Relationship diagram below: 
business logic on the client. How can an application repre- PIG. 125 illustrates an activity entity relationship dia- 
sent and reuse "client-side** business logic across multiple, 25 gram- 
volatile user interfaces? While any user interface maintains a reference to the 

Imagine a typical client/server system design. In almost Activity 12500 it provides an interface 12502 for, the 

all cases, a typical system executes data access logic on the Activity is unaware of what (if any) interfaces exist on it. 

server and presentation logic on the chent, business logic is This decoupling allows for a large amount of flexibility with 

split across both the client and server. The majority of this 30 interfaces to an application. Multiple types of interfaces 

business logic is maintained on the server. This logic is can exist on a single type of Activity. Code is reused and 

represented by various components and business objects that none is lost if presentation logic is replaced with something 

can conmiunicate with each other to complete a variety of different. 

system use cases. While a user interface can communicate directly with its 

The client, on the other hand, is mostly responsible for 35 associated activity, an activity should never directly com- 

supporting user interactions with the system. To be municate with any of its interfaces. This would set up a 

successful, the client must also execute some degree of dependent relationship that would reduce the flexi'bility of 

business logic. While this can vary from implementation to the activity. Instead, an activity can communicate to its 

implementation, some categories of logic are invariably interfaces through an event mechanism. Interfaces are set up 

located on the client. This includes simple data validations, 40 as dependents of the activity and the activity sends events to 

representing data structures and relationships, error and ^ of the interfaces on it. Each interface can decide how to 

exception handling, and communications with the server. handle the event. 

To complete a single use case, the client may need to FIG- illustrates a roles and responsibilities diagram, 

interact with a number of server components. From the Benefits 

user's perspective, one unit of work is being performed but 45 Maintainability. By separating the presentation and non- 
it may involve multiple, discrete interfaces and multiple presentation logic, the client is easier to understand and 
server invocations. Some business logic is required to man- maintain. 

age the complex flow to complete this unit of work. For Reuse. The presentation layer may be replaced or reused 

example, suppose a use case for a network inventory man- without affecting the non-presentation logic, 

agement system is "Add Network Card". This may require 50 FIG. 127 illustrates a typical impIemenUtion between a 

the user to input information in three or four screens and user interface and its activity. 

chent communication with more than one server component. The diagram shows the various "layers" of interaction 

Managing this flow is not the responsibility of the presen- where the lightest shaded boxes are the presentation, the 

tation logic but still needs to be executed on the client. next darkest is the activity, and the darkest is the component 

The system may also require a number of interfaces to 55 (proxies 12700). 

complete the same use case. Depending on the user category A user request is captured and processed by the presen- 

executing the use case, the interface may be a PC, a tation object (NetworklnventoryUserlnterface 12702). In 

handheld device, or a telephone. Even on the same type of this case, the processing involves simple validation (format 

device, the interface may differ depending on the user and "is null** checking). 

category. Some users may want to access the application via 60 The presentation object then copies its data into a struc- 

a standard Windows interface while others may want to ture representing some business entity (aNetworkltem 

access it via a "web-centric** interface (internet browser). In 12704) and passes it to the activity 12706. The presentation 

all of these cases, the unit of work to be completed by the object then triggers the activity to start its processing of the 

user is not changed and should be reused. new network item. 

FIG. 124 illustrates multiple interfaces to an application 65 The activity then performs possibly more complex vali- 

12400 including a handheld device 12402, a desktop PC dation and communicates with the server components to 

12404, and a telecommimications device 12406. complete the use case. 
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Collaborations 

Facade — ^The Activity acts as a Facade to all of the server 
coiDponents by coordinating a user interfaces interaction 
with them. 

Separation of Concern — ^Dividing defined re^nsibilities 
into separate classes (presentation logic into UI classes and 
client-side business logic into activity classes). 

Observer — An activity's interfaces are observers of that 
activity. 

User Interface Validator 

FIG. 128 illustrates a flowchart for a method 12800 for 
structuring validation rules to be applied to a user interface 
for maximum maintainabihty and extensibility. In opera- 
tions 12802 and 12804, a plurality of user interface widgets 
are provided along with a plurality of validation rules which 
govern use of the user interface widgets. A user is allowed 
in operation 12806 to select the validation rules to associate 
with the user interface widgets of a first user interface. The 
validation rules of the user interface widgets of the first user 
interface are automatically associated across a plurality of 
separate different user interfaces in operation 12808. 

Tbe validation rules may be created at the time the first 
user interface is created. As another option, the validation 
rules may be implemented by a different class for each type 
of validation. As a further option, an indicator may be 
displayed upon one of the validation rules being violated. 
Additionally, each validation rule class may exteiKl an 
abstract validation rule class that defines what types of 
widgets are supported. Also, a request for the validation 
rules may optionally be received from one of the user 
interfaces. 

How can you structure validation rules to be applied to a 
user interface for maximum maintainability and extensibil- 
ity. 

Imagine a typical Windows or web-based client/server 
application. In most cases where a "windows'* type of user 
interface is provided, an application supports some business 
rules by validating data entered by die user. A common 
example of this is checking the format of data in an entry 
field or ensuring that a required field is not left empty. 

The business rules supported by user interface validation 
is usually somewhat limited. The scope of these rules is 
generally constrained to checking if a field is empty, ched^- 
ing the format of a field (date, time, nimaeric, currency, etc.), 
and checking if a field has alpha-characters, numeiic- 
characteis, or both. In addition, due to fact that many 
widgets provide constraints through their own form (list 
boxes, radio buttons), the types of widgets that require this 
type of validation checking is also somewhat limited (text 
fields, editable combo boxes, etc.). 

FIG. 129 illustrates widgets with their validation require- 
ments 12900. 

Because this type of validation will most likely be 
required across all of an application's user interfaces and the 
fact that the types of validation rules and widgets needed to 
validate are Umited, this behavior is a strong candidate for 
a framework. 

The framework would provide a common approach to 
validating user data across aU of an application's user 
interfaces. Rules would be applied consistently throughout 
the application. While some common validation rules would 
be provided, the framework needs to allow their behavior to 
be modified (overridden) and make it easy for new rules to 
be added. 

Finally, both immediate and batch validation should be 
provided by the framework. 

Therefore, for each user interface in an application, 
encapsulate their validation logic in a User Interface Vali- 
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dator. FIG. 130 illustrates a user interface validator associa- 
tion diagram. A User Interface Validator 13000 associates 
various validation rules with the user interface widget they 
are to be applied to. 

The associations are created at the time the user interface 
is created. The validations are triggered when deemed 
necessary by the user interface. Any validations that fail are 
displayed to the user including the type of validation that 
failed and the widget that it failed on. 

The rules are implemented by a different class for each 
type of validation. Each of these validation rule classes must 
know how to check its rule for every type of widget that can 
be checked. As mentioned in the Context section of this 
pattern, this will most likely be limited to text entry type 
widgets. In addition, each validation rule class extends an 
abstract validation rule class that defines what types of 
widgets are supported. This is an implementation of the 
Msitor pattern. 

FIG. 131 illustrates a validation rule class diagram. 

Note that the check operations accept a Validate 13200 
type of class. Each widget that can be validated with this 
framework must implement a validateRule method. This 
simple method accepts some ValidationRule 13202 as a 
parameter and simply turns around and calls the check 
method on the rule passing itseff in as a parameter. This 
interaction is shown in FIG. 132, which illustrates a rule 
validation interaction diagram. 

The concrete implementation of the check method will be 
invoked. This method knows how to extract the data from 
the particular widget provided and verify the rule. 

The User Interface Validator's job is to associate these 
rule instances with all of the widgets they pertain to. When 
the validate method is invoked on the Validator, all of the 
rules are sent to each of the appropriate widgets via the 
validateRule method. 

New rules can be added by creating new classes that 
extend off of the abstract Validation Rule class. No dianges 
need to be made to the widgets. 
Benefits 

Consistency. All user interface validation rule checking is 

done in the same way using the same rule logic. 
Extensibility. New rules can be added without affecting 

any other part of the application. 
Automation, ^plication of validation rules can be auto- 
mated with a GUI based tool rather easily. 
The associations between a widget and the rule to apply 
to it should be set up when the user interface is created. A 
user interface can implement a method that accepts a rule 
and widget and passes it on to the User Interface Validator 
as shown in the code example below: 

ValidateTextField userNameField«new TextField("user 
name"); 

ValidateTextField passwordField=new TextField 
("password"); 

ValidateTextArea commentsArea=new TextArea 
("comments); 

this.addValidation(userNameField, new 

NotEmplyValidationRule( )); 
this, add Validation(passwordField, new 

NotEmpty ValidationRule( )); 
this.addValidation(passwordField, new 

NotNumericValidationRule( )); 
this.add Validation(commentsArea, new 

MaxLengthValidationRule(255)); 
The addValidation method on the user interface is shown 
below. 
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public void addValidation(ValidaleWidgel aWidget, Vali- 
dationRule aRule) 



a startup event of an activity has occurred in operation 
13302. A reference to a first instance of an object created by 
the startup event of the activity is also received in operation 
13304. In operation 13306, a view to launch is determined 
5 in response to the receipt of the notification and the refer- 
ence. The view is based on predetermined criteria. The view 
is associated with the activity and displayed in operations 
13308 and 13310. 

The predetermined criteria may include user preferences, 
an experience level of a user, security profiles, and/or 
workflow settings. Also, the activity may be allowed to run 
without a corresponding view. The activity may also operate 
on a machine separate from a machine of an end user. 

As an option, a request may be sent to be notified when 
a new instance of an object is created. As another option, a 
^5 configuration file may be read for obtaining configuration 
information. 

How do I associate a new view with the appropriate 
business activity underneath, in a configurable manner? 
Consider a user interface that displays and collects data 
20 for an activity object underneath. 

The ICM/MVC patterns provide for a layered architec- 
ture. Each layer talks to a layer below it, and no lower layer 
talks to an upper layer. For example, the view messages 
In the above code, three widgets are created and then downward to the activity and the business objects, and the 
associated with various validation rules. The user name and ^ activity messages to the busmess objects. Layers talk down, 
password fields are required and cannot be left blank, the ^o layer messages back upward. 

password may not contain any numbers, and the comments Traditionally, activities launch their views directly. In the 
text area may not be longer than 255 characters. example illustrated below, the Search Mew tells the Search 

Note that each of the widgets is created with a string that Activity to launch the Customer Maintenance Activity, 
describes a name for the widget that the user would recog- 30 which then opens up its own view. But this violates the ICM 
nize. This name is used in the error list to help a user identify approach, because then the model is talking directly up to 
which widget failed validation. the view. 

At some appropriate time, the user interface sends the FIG. 134 illustrates a manner in which the maintain 
validate message to the User Interface Validator. This customer activity operation 13400 of the present invention 
method steps through each of the rules provided to it when 35 launches its view 13402. 



UlWidator myVWidator = this.gctVbHdator( ); 
My^lidator.addAvl£datioii(a\^^t, aRulc); 



The add Validation method on the User Interface Validator 
is shown below. 



public void addWidation(V^lidateWuiget aWidget, \%lidatioiiRule 

aRule) 

{ 

Hashtable mlcsAndWidgets = this.gctRulesAndWidgcts( ); 
if (mlcsAndWLdgets.coiitainsKey(aRule)) 



} 



{ 
} 

rulesAndWtd^ts.put(aI^Iey aV^get); 



aRulc " aRale.clone( ); 



the user interface initialized and passes them to their asso- 
ciated widget by the validateRule method. The code is 
shown below: 



public Vector validatc( ) 



{ 



Vector errors = new Vx4or( ); 

I^htable rule&And^dg^ = this.gctRulesAnd>^1dgets( ); 
Enumeration rules » nileaAodV«^gets.kcys( ); 
while (Tules.hasMoreEleinents( )) 
{ 

MdidationRule aRule - (\^i^^iiRuIe)niIesjiextEleinent( ); 
\WidateWdget aWidget - (VfelidateWidget) 

RulesAndMdgets.get(aRule); 
String anError - a\^dgeLvalidateRule(aRuIe); 
if (anEnor t- null) 



{ 



It might be more appropriate to let the view layer, rather 
than the activity layer, make decisions about launchiiig other 
views. The view layer already knows about usability 
preferences, positioning on the screen, etc. However, one 
40 wants the activities to control conversational flow for 
preconditions, postconditions, workflow, and any other addi- 
tional business logic. 

A view should not be able to launch a new, separate 
activity, because that involves business Ic^c. Instead, one 
45 wants activities to launch other activities. When the activity 
layer controls conversational flow, one needs a mechanism 
to launch views on top of these activities, without violating 
ICM. 

Therefore, a \^ew Configurer 13500 wiU be created to 
50 manage the relationship between activities 13502,13504 and 
views. This would likely be a singleton. 

FIG. 135 iUustrates the view configurer 13500 launching 
the maintain customer view operation. 

The View Configurer is a generic mechanism which 
55 allows launching of different views, based on certain crite- 
ria. It uses an observable relationship with activity factories 
Note that in the code example above, the validateRule solve this problem. With the \^ew Configurer, developers 
message returns a String rather than a boolean. This string do not hard code the particular policies for the selection of 
can be passed back to the user interface that invoked the a view. Moreover, this mechanism aUows activities to run 
validate and used to describe the errors that occurred to the 60 without a corre^nding view. 

user. Communication from the activity to the View Configurer 

CoUaborations will be conducted through broadcasting (as described in the 

Msitor Each of the rules arc implemented as a \%itor Observer pattern). In this manner, the activity doesn't know 
according to the GoF pattern of the same name. about the existence of the Mew Configurer, it listens to 

\^ew Configurer 65 activity broadcasts such as when the controUer starts up. 

FIG. 133 iUustrates a flowchart for a method 13300 for This configurer can use the Observable Factory to get a 
assigning a view to an activity. Notification is received that handle to lie activity instance. 



eitois.addElement(an£rror); 



} 



return errors; 
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Hiere are four main stqjs involved with the \^ew Con- Operating System Services 

figurer observer/observable interface: Runtime Services 

Prior to the flow depicted above, the View Configurer has Version Management 

registered with the Activity Factory saying "TeU me when a Ucensinc Sendees 

new instance is created'*. This is an example of an "Observ- c t- »t ji- /t 

able Factory," which can be thought of as a Factory which HandhngyT^gging Services 

implements the subject/observable role of the Observer Properties 

pattern. The Factory needs to be a singleton, so the View Memory Management 

Configurer has visibility to it. Security 

The Search Mew tells the Search Activity to launch the "Miscellaneous services** should not be interpreted as 

Maintain Customer Activity. "less important services." In fact, they are vitally important. 

The factory for the Maintain Customer Activity creates a Developers are more productive when they are not required 

new instance of the Maintain Customer Activity. 1° ^ concerned over logging and auditing, error handUng 

Because the \^ew Configurer has pre-registered an inter- context issues. Obtaining the freedom to largely ignore 

est in the startup of activities, it will receive a broadcast requires close attention to providing facilities 

message. In this step, the View Configurer should receive a ^^^^ thought out and meld into the appUcation 

minimum of two parameters: structure. 

Notification of the startup event that has just occurred. Despite the pervasive demands of environmental 

Areference to the new instance of the object that was just ^^^^f^^^^^ions, many fom^s of documentation largely ^oss 

created ^^^^ issues. For example, many times when reading 

The View Configuier then determines which view to API do«:umemation we find authors disclaim ±e fact lha 

launch. This can be based on a variety of criteria, such as °' ptograrmmng by contract" ,s shown 

user preferences, experience level, Lcurity profiles, or wahin«te«=odeex^^^^ 

workflow settings, lie configurer determines the co;rect ^andhng nght is key to stahihty m the execuUon 

view and attaches it to the activity underneath. . envuonment. Programmmg by contract with the use of 

ggjjggjg 25 preconditions and post-conditions is perhaps the most 

1 , *i_ J . * ^- J 1 - aggressive style of programming known to date to assure 

Development. Dependmg on the distribution model in programs. A^ition, Exception Hierarehies. Excep- 

place, busmess processing can be ex^nited and tested ^^n Response Table and Polymorphic Exception Handler 

before Uie appropnate views have been miplemented. tacMe these problems vigorously b^helping to de&^^ 

Autornated testmg. The View Configurer is particularly 30 how to solve some of these key kernel apphcation architec- 

useful when you want to use scripts and avoid bringing ture considerations. The Exception patterns provide a blue- 

up v^doA^ with automated testing. This is especially prfm illustrating how architectural issues can be abstracted 

true for performance testing, where you might want to into a service level component so that the impact to the 

run 100 transactions, which might involve instantiating application code is minimal 

100 mstances of the same activity 35 A demanding issue in distributed systems is gathering and 

Runnmg processes m batch mode. The View Configurer using trusted information about the clients interacting with 

allows processes to run without a View, and makes it the systems. In earher generations of systems the number of 

very sunple to connect, disconnect, or reconnect related users was a fairiy precise calculationH«st count the number 

views. of workstations "which could potentially connect to an appli- 

Distribution Transparency. In a distributed environment, 40 cation. Information about the users was also a fairly simple 

the process might live on a di£ferent machine from the matter since they connected directly to the resources from 

end user's machine. In that case, it cannot launch the which they were requesting services. Today, with cHents 

view directly, within its own executable. (Unless using offering web services within n-tiered architectures this is no 

a remote windowing system like X-windows, etc.) So longer easily predictable. In addition, requirements to sup- 

the \^ew Configurer allows appUcation architects to 45 port these less predictable numbers of users and to have a 

transparently move process logic around, depending on personal "one-to-one" relationship with them is key to many 

the distribution model. web strategies. The LoadBalancer and UserContext pattern 

Collaborations offer some help in this area. The former addresses strategies 

The Observer Pattern (Gang of Four Pattern) describes for ensuring maximal leverage of the system resources and 

how to provide visibility to other entities via a one to many 50 services and the latter helps in addressing the issue of 

relationship. A singleton activity factory will create new maintaining state and context about the user. These facilities 

activity instances, and broadcast the startup of the new are mandatory when security, auditing and logging are 

activities to the View Configurer. considered essential properties of the environment. 

An interface for the creation of activities is used in Assertion 

conjunction with the Observer Pattern. In this way, the 55 FIG. 136 illusti^ates a flowchart for a method 13600 for 

startup of new activity instances can be broadcast to the testing successfulness of an operation having pre-conditions 

\^ew Configurer. This is described in the Factory Pattern and post-conditions that must be satisfied for the operation 

(Gang of Four Pattern). to be successful. A first assertion is raised in operation 13602 

Generally, there will only need to be one View Configurer asserting a pre-condition that must evaluate to true if the 

per executable. The View Configurer would likely be a 60 operation is successful. The operation is then executed in 

singleton, as described in the Singleton Pattern (Gang of operation 13604. A second assertion is raised in operation 

Four Pattern). 13606 asserting a post-condition that must evaluate to true 

Environment Services (1016) if the operation is successful. An error message is outputted 

Environment Services provide miscellaneous application upon failure of at least one of the assertions in operation 

and system level services that do not deal directly with 65 13608. 

managing the user-interface, communicating with other Optionally, an error handler may be provided for detecting 

programs, or accessing data. These services are divided into: a failure of the assertion of one of the conditions and 
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shutting down a system running the operation upon the An Assertion accepts conditions that must always evalu- 

detection of the failure. As another option, an assertion may ate to true. If any of these condidons ever fail, a critical error 

be raised at the beginning and end of every operation of a has occurred and the system should shut down. Pre- 

plurality of operations. Also, a check may be performed conditions and post-conditions are good examples of the 

prior to raising the assertions for determining the propriety 5 type of conditions that should be asserted during an opera- 

of raising the assertions. tion's execution. 

Each assertion may be raised with descriptions for helping The Assertion class is passed a condition that, if evaluated 

to Identify where the assertion failed. Also, each assertion to be false, raises the appropriate errors and shuts the system 

rnay be raised with parameters for helpmg to identify why down. The purpose of this pattern is to formaUy recognize 

the assertion failed. In one embodiment, two types of lo the pre- and post-conditions of a method in the actual code 

assertion classes may be provided. In such an embodiment, rather than through developer comments. By implementing 

one of the assertion classes may implement assertion- an assert( ) method on a common superclass, the interaction 

checking logic and the other assertion class may implement with the Assertion class can be hidden from the functional 

only null operations, with one of the assertion classes being developer. An example of the use of assertions is shown 

selected to be raised. 15 below: 

Every operation has a set of preconditions and postcon- 
ditions that must be met for the operation to be considered 

successful. If these expectations are not met, the system state ^— ^— ^— 

is in error. How can operations check for these errors so that public Customer CTeateCustomer(int newCustomerNumber) 

the handling of these critical errors are consistent across the 20 ^ rN«v„„ . .. ^ . 

t - . . Customer newCustomcr « null; // declare the new customer 

application. this.asscrt(newldciitifier > oy/ pre-condition, a customer's 

Methods typically obtain and return a value, set an // identifier must be greater than 

attribute based on a passed in parameter, or modify the state // 
of the application based on some complex business rule or i^^"" "Zr^!^!" nx » 

1 * «7u-i *L * t . * , . thisasscrt(ncwCastomcr 1= null); // post-condition, the costomer 

ruleset. While there is always some expected result of the 25 was y> /' > ^uj^^j 

invocation of an operation, there arc also other, less expected // created 

possibilities. The provided parameters may not be within the ncwCostomcr, 

ejqpected range, thereby causing an error. A communications I 

faihirc could cause the operation to fail to complete or, 

worse yet, return incorrect data or leave the system in an 30 Assertions can be raised with descriptions and param- 

inconsistent sUte. eters. A description can help to identify where the Assertion 

Any complete design determines that some fonmal sped- failed and a parameter list can help to identify why the 

fication is required to ensure operations complete correctly. Assertion failed. 

This specification is most often in the form or pre- and Assertions should be raised at the beginning and end of 

post-condiUons. These condiUoi^ define a set of logical 35 every operation. Prior to raising the Assertion, a check 

expressions that must hold true for the operation to begin should be made to see if it appropriate to raise one (if 

and end as expected. These conditions are usually defined assertions are enabled, if performance sensitive assertions 

dunng the Design Phase of development. An example is are enabled). This can be accomplished by querying the 

in the Operation Diagram below: Assertion class for its state before checking the asser^on: 
HG. 137 illustrates an operation diagram depicting an 40 
example of pre-conditions 13700 and post-conditions 

13702. , 

The conditions, in short, define the contract for the ifl[IAssertion.isPerfonnanccSensitive()) 

method.Allof these pre-conditions must hold true before an ^ 

operation's execution and all of the post-conditions must 45 j 

hold true after an operation's execution. Only then is the 

operation said to be successful. If any of these conditions 

fail, a critical error has occurred. The system must assume ^ operations will have both pre- and post-conditions. 

it is in an inconsistent state and cannot continue processing. Even in cases where an operation defines an input parameter 

It is expected that the system programmers will check for 50 ^ something as broad as an integer, it is doubtfiil that all 

pre- and post-conditions systematically in the operations integers are acceptable to the operation. In this case, an 

they are coding. This seemingly simple requirement Assertion should be raised to chedc if the parameter is in the 

becomes non-trivial when some issues are considered: appropriate range. 

How can multiple developers implement these checks in A "top-level" error handler should be defined to catch all 

a consistent manner? 55 AssertionExceptions and handle them in a clean and con- 
Some condition checks may be expensive to complete sistent maimer. This should include reporting the assertion 

(database and remote component queries). How can these be failure and shutting down the system following an orderly 

turned on and off to meet performance expectarions? Prob- procedure. 

lem with deferred evaluation; see below. It is important to note the difference between assertions 

How can the exceptions raised when a condition check 60 and standard error-handling. Assertions are condition checks 

fails be handled in a consistent manner throughout the that can be turned on and off dming runtime whereas 

system? standard error handling is always enabled. This is because 

Therefore, a type of object should be developed to rep- assertions must always be true. The burden is on the testing 

resent a check against an operation's conditions. This process to catch aU failed assertions. Thus, a failed assertion 

generic class of objects is known as an Assertion. v^Iica- 65 should simply never happen in deployed code. However, 

tion developers should then raise Assertions throughout the exceptions can happen, and therefore cannot simply be' 

system to check the correctness of the code and system state. turned off. 
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Benefits mined intervals for determining whether a predetermined 
Ease of Error Identification. Many error are caused by amountof time has passed since each of the objects has been 
invoking an operation with improper data (parameters). accessed in operation 13810. Contexts that have not been 
By formalizing these conditions, it is very obvious is an accessed in the predetermined amount of time are selected in 
error was caused by bad data or bad code. 5 operation 13812 and information is sent to the clients 
Cbnectness. Properly placed assertions assure that the identifying the contexts that have not been accessed in the 
system is in a correct state and responses can be trusted. predetermined amount of time in operation 13814. 
Assertion checking complements, but does not replace, waiting a preselected amount of time for receiving 
a comprehensive testing program. The responsibility * response from one of the clients, the context may option- 
remains with the designer to identify the correct con- }^ ^ * response from one of the clients is not 
ditions to assert. received within the predetermined amount of time. Also, a 

. All u 1 11 u J J i_ ji J - response may optionally be received from one of the clients 

Consistency. All checks will be made and handled m a ^T.-^r *u * f *u * ^ u • * • j t i_ 

similar fashion requestmg that one of the contexts be mamtained. In such a 

situation, upon receipt of the response, a time the context 

Control. The enablmg and disabling features of the Asser- 15 was last updated may be updated to a current time. 

tion allows an operations controller to determine when As a further option, a queuing delay may be accommo- 

and what checks should be made at runtime rather then dated for a response from the clients. Also, each of the 

development time. ^^^^^^ j^^y maintain a coUection of aU objects the client is 

Flexibility. All handling and clean-up of incorrect asser- interested in. The clients then may send requests to keep 

tions is located in one place making changes to this 20 alive any objects the clients are currendy interested in. 

logic much easier to implement. A client requests a server process but due to abnormal 

Readability. Polices concerning how assertions are actu- circumstances fails to clean up. How is the orphaned process 

ally thrown and handled is not in the functional code. detected and removed? 

DocumenUtion. The code actually documents the design ^ * stateful server, die LUW Context pattern 

assumptions. This can also be used by documentation ^ facilitates the server process constructing domain objects at 

generators which read through the code. ^® request of the clients and maintaining these objects 

The Assertion class can be defined as shown in the ^^"^ * Siven context. Domain objects are entered into a 

following specification: registry with their appropriate context which the server 

Class Assertion maintains and updates when a request is received to create 

void raise(boolean condition) throws AssertionExcep- an object^ Each time a context is accessed then a 

^l^jj notification is broadcast to the registry, regardless of a state 

void raise(boolean condition. String description) ^^^^^e. With a simple context management, each time a 

throws ' & 1- / context is referenced by a chent a reference counter is 

. incremented and similarly decrements when the reference is 

Assertionfcxception ^, . „ 35 destroyed. Once the reference count returns to 0 then the 

void raise(boolean condition. Vector parameters) ^^^^ ^ ^ ^^^^^^ ^^^^ 

. If the context is not explicidy deleted by the client then it 

AssertionExoeption ^1 remain in the registry as the server has no way of 

void raise(boolean condition. Vector parameters, String detecting that the context is orphaned. 

description) throws AssertionExoeption 40 Even if the client application is rigorously designed to 

boolean isEnabled( ) ensure all redundant contexts are deleted, an abnormal cUent 

boolean isPerformanceSensitiveEnabled( ) event may result in its termination leaving an orphaned 

Class AssertionException extends Exception server context. 

One possibility on how to handle the enabling and dis- FIG. 139 illustrates a Client 1 13900 that has instantiated 

abling of assertion checking would be to have two possible 45 A 13902 and C 13904, deletes C but fails to delete A. 

types of Assertion class. One which implements the actual The server still has a reference counter greater than 1 even 

assertion-checking logic and another which only imple- though the client is no longer interested, 

ments no-ops. The Assertion instance is then obtains through Therefore, Distributed Garbage Collection should be 

an AssertionFactory which can be set as to which of the two implemented to ensure that orphaned server contexts are 

types to distribute. These settings are determined at runtime. 50 deleted on the server. In the registry for the Garbage 

It should also be noted that in Java, the exception that is Collection the server maintains a collection of outstanding 

thrown should be a generic run-time exception that doesn't server (Ejects and for each c^ject a list of its contexts, the 

need to be caught by the method or mentioned in the clients currently interested and the duration since a method 

method's throw clause. was invoked upon a given context by a client. Periodically 

Collaborations 55 this list is examined to establish if any of the objects have not 

Factory been accessed for some configurable time and are candidates 

Distributed Garbage Collection for reaping. So, for example, a value of 5 minutes could 

FIG. 138 illustrates a flowchart for a method 13800 for serve as a default poll event or keep alive interval. If a 

detecting an orphaned server context. A collection of out- candidate for a orphaned server process is identified then the 

standing server objects is maintained and a list of contexts 60 clients are sent a message, requesting if they are still 

is created for each of the outstanding server objects in interested in the context. This might be performed by 

operations 13802 and 13804. A compilation of cHents who pubhshing an "is anyone interested** message to the regis- 

are interested in each of the outstanding server objects are tered clients to establi^ if anyone is interested in the object 

added to the list in operation 13806. Recorded on the list in in its assigned context or by asking the clients explicitly 
operation 13808 is a duration of time since the clients 65 depending on the nature of the architecture, 

invoked a method accessing each of the contexts of the The client side also maintains a collection of all of the 

outstanding server objects. The fist is examined at predeter- objects that it is interested in. When it is queried, it instructs 
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the server to keep alive any objects it has ao interest in for be partitioned into classes based on the way exceptions are 

which a query has been received. handled, exceptions associated with different layers of a 

FIG. 140 illustrates a GarbageCbllector 14000 requesting system, domains, and/or the source of the exceptions. As a 

for interest in context A 14002. No re^onses are received further option, a class may be created which represents a 

from any clients so the server assumes it is orphaned and 5 source of the exception and holds an original copy of the 

elet^ It. exception for avoiding creation of duplicate exceptions. 

If the penod config^red for a chent to respond expires ^Iso, arbitrary exceptions may each optionally support a 

then the context is dele ed. This accounts not only for an ^j^^ creates a copy of L arbiiary excep- 

abnormal termination ofthe chent but for failure of the chent ^^^^ j r 

application to clean up. However, if a request is received Developing exception handling logic without classifying 

from a client to maintain a context then the tune the context ^ orgamzing exceptions makes thi handling logic aun- 

was last accessed IS updated to the current tune and it ^ersome and fragfle to change. How should exceptions be 

remams m the Garbage Collection registry. structured? 

FIG 141 iUustrates a GarbageCollector 14100 requesting The traditional way of conveying errors is by passing 
for mterest in context B 14102. Client 2 registers interest so ^^es from callee to caller. Tli^ approach is adequate 

^e r^per updates the access time stamp and maintains B. ^^me cases, but in general, it is less powerfiil and more 

error prone than an exception based approach. In the tradi- 

Qeanup on the Server. Reduces the amount of redundant tional approach, only minimal information can be passed, 

resources on the server to a minimum. This is espe- s^ch as a failure to locate a configuration file (information on 
cially unportant if a statefiil component is held in a 20 which file has to be provided by some other means). It is also 

transaction by a cUent and the architecture prevents very easy, and common, to ignore the return code. Projects 

additional clients fi-om accessing it, e.g. with BEA's which faithfully test every return code end up mixing a high 

^* percentage of error logic with the primary logic. This 

Performance. Ensures that only the required contexts are increases the complexity, and the development, review, and 

maintained on the server, minimizing the work that the 25 maintenance effort 

server is required to do, especially during the cleanup Some computer languages (Java, C++) support an error 

process at the end of a LUW. reporting mechanism based on exceptions. In these lan- 

Centralization. The collector has a central view overall of guages an exception can be a class type and hold arbitrary 

the contexts that are currently accessed by all of the information, such as the name of the configuration file that 

clients within a given context. This simplifies the 30 was missing. Also, exceptions cannot be as easily ignored as 

persistence of a context at the end of processing. return codes. If the callee raises an exception and the caller 

In order to prevent potential race conditions the client doesn't handle it, the caller's caller is checked to see if it 

must be given suf&cient time to respond to the keep alive handles the exception. TTiis continues until the exception is 

message from the server before the context is deleted. handled or the program terminates. Designed properly, the 

Typically the client has a separate listener for upward 35 error handling logic will be somewhat separated from the 

messages originating at the server, so queuing is not an issue primary logic and will be less dense than the traditional 

at the client end. However, a server is more likely to queue approach. 

on the receiving end, especially in a system with high The exception class designer is free to create any interface 

message rates. for the class, and each exception class can have its own 

Unless there is a dedicated listener on the server it must 40 unique interface. The exception handling logic 14300 will 

be configured to accommodate for any queuing delay on know which exception 14302 was raised (via runtime 

receipt of the client response. support) and can make use of the interface particular to the 

Collaborates with given exception. You can think of the exception handling 

Context Pattern Language descnt>es the architecture that logic being a set of "chunks'* of logic where each chunk 

is required before the Distributed Garbage Collection is 45 handles a specific type of exception. Wth this in mind, you 

required. can see how having many different exception types will 

Variation of cause the exception handling logic to grow. As a new 

Java Shared Namespaces with distributed garbage collec- exception type is added to the system, a new "chunk" might 

tion. have to be added to the handling logic. This is not good. The 

Objectstore PSE WeakArrays. 50 code is not flexible to change and is in several places. Note 

Exception Hierarchies FIG. 143. 

FIG. 142 illustrates a flowchart for a method 14200 for Suppose you have all these chunks of handling logic and 

creating a common interface for exception handlmg. Nam- discover that the logic is pretty much the same. For example, 

ing conventions of exceptions are determined in operation assume your architecture is layered and you want to treat aU 

14202. A prefix and/or a sufSx is added to each exception 55 exceptions from the persistence layer the same, such as 

interface name in operation 14204 for indicating that the logging the error and notifying the user. Also assume that the 

exception interface is an exception. In operations 14206 and persistence layer can raise any one of fifty exceptions, and 

14208, where an exception error occurred is indicated and a more are expected to be added in the future. This is fifty 

determination is made as to what caused the exception error. chunks of code that must be present in the exception 

Context is provided as to what was happening when the 60 handling logic, and again, this logic may be in several 

exception error occurred in operation 14210. Streaming of places. Wouldn't it be nice to write one chunk of handling 

the exception is allowed to a common interface in operation logic and be done with it? 

14212. An error message is ou^utted indicating that an Let's take another scenario. Suppose you want to prevent 

exception error has occurred in operation 14214. any raised exception from bringing down your system, as 

As an option, a layer and/or domain may be added from 65 least not without a fight. In some cases the error will be 

which each exception originates to each of the names of the unrecoverable and there is not much you can do but release 

exception interfaces. As another option, the exceptions may resources 0ocks, communication channels, . . . ) and termi- 
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nate. What caused Ihe pioblem is going to be on the tops of Consistency. Consistent approach to error handling, 

the minds of the production support people, and yours when Maintainability. Minimizes coding changes by reducing 

you get their call (always in the middle of the night). You the multiple number error handling chunks, 

could wnte the exception handling logic chunks for each Manageability. Provides Conceptual Framework 
exception type-«membering that each exception has its 5 jhe solution section covered many of the considerations 

own mterface and wiU require separate logic to handle each i, creating the exception tree so this section only provides 

mierface— for each exoepUon, but now you have to handle some additional details to consider 

all the exceptions in the system. Wouldn't it be nice to write Wron«;.,„ .4»u...<.v„ k„ ,™j . • i t • 

one chunk of handling logic and be done with it? ^2 .1^Jn^^r^ . T^ ^Tk . ^ 

TTierefore, to simpl^ the error handling logic and be able „^^xT" h " t k ^""^"^ apphcalion 

. . . r *- .1. r . . - 10 and the need or desire to handle server and chent 

to treat groups of exceptions the same, a few techmques A-re *i ♦ i r IT 

cK^i.t^ ^T^of^ f • A A G *u ^^H^^^ exceptions differently, or to know the source of the 

should be used to organize and define the exception mter- „ n , ^. jl i- . 

^ vA^i^iiwu ujivi gj^j. ^j^y avoid creating duplicate exceptions 

Ti^L * - * * * . ^ « (one per source) is to create a class which represents the 

The first step is to create an exception mterface that all L„ Jl ^„a u„w .u • • i ^- i 

-^t^^ „ n ^ J ¥* • . . source and holds the ongmal exception. For example 

other mterfaces will use or extend. It is not possible to a«c^«,^,t3 ™ u ijT • * * i_ 

provide one here as it greatly depends on the re^ments 15 ^^"'S^^u^r ^ ^ " ^ 1 a"^"^ 

at hand. But here are »me|uidSnes: ^^^^ ^^"^ T ^T'^'? 

_ . * . . exceptions and then access the held exception. An 

Determine the ex«ption naming convenUons. Use either alternative is to put a code in the base class with 

a prefix or siflSx to indicate that the interface is an indicates source but then all logic needs to know to set 

exception. Also consider naming exceptions with Ihe Oiis vahie and all handling logic needs to test for it 
layer or domain they ongmate from. For example you ^ To hold onto an arbitrary excepdon you need a way of 

may have an excepUon, CaAddre^Excp. which is creating a copy of it. but you^nay not know the actual 

owned by the Customer Acqui^tion domain. ^ ^^^^^ ^ ^ 

Provide a means to determme where the error occurred destroyed when you leave the handling logic, so you 

(file, line, chent or server, layer. . . . ) so that it can be ^ need the ability to create a copy to hold onto. A 

mves ga . common technique is it have all exceptions support a 

Provide a means to determine what happened (could not "clone" method which creates a copy of themselves, 

open file: XYZ). Consider how to stream an exception so it can be sent 

Provide context as to what was happening (Saving from server to client, 
account information). ^ Exception Response Table 

Provide a way to stream the exception or stringify it. FIG. 145 illustrates a flowchart for a method 14500 for 

Consider separate production messages veisus debug recording exception handling requirements for maintaining 

messages. a consistent error handling approach. An exception response 

Don't try to indicate severity. This is determined by the l^We is provided in which an exception is recorded in 
context of the caller, not the callee. 35 operations 14502 and 14504. The context of the exception is 

The intent is to be able to handle any arbitrary exception entered in the exception response table in operation 14506 

the same by having a common interface. Take time and get a response for the exception is listed in the exception 

this right, to avoid updating several other exceptions later. response table in operation 14508. The response is subse- 

Now that this base exception interface is available, any quently outputted upon the exception occurring in the con- 
handling logic can treat all exceptions alike; only one chunk 40 ^ operation 14510. 

of logic needs to be written. Specific exceptions can still be A typical response and a last resort response may be listed 

handled on a case by case basis as required. You can extend in the exception response table. The typical response may 

this concept to fiirtter partition the exceptions by creating a ^ outputted upon the exception occurring in the 

tree of exception types. By handling any exceptions at context. The last resort response may be outputted upon the 

particular point in the tree, you effectively handle all excep- 45 exception occurring out of the context. Additionally, abbre- 

tion types below that point. The trick is in creating a usefiil viations may be used to reduce an ou^ut size of the 

tree. Here are some guidehnes: exception response table. Further, the exception response 

Determine where handlers will be put and how they will table may also include an exception category field for 

respond to each exception. If you find that many are handled permitting organizing multiple exceptions by source, 

in the same way there may be a natural grouping that can be 50 Optionally, an optimization may be determined that can be 

leveraged. made based on similar entries in the exception response 

Consider the stability of your grouping. Is the group table. Further, the optimization made may also include 

cohesive or is regrouping likely? classifying the exceptions for organizational purposes. 

If parts of your system are layered, consider a branch that The response to an exception may vary per exception type 

consolidates each layer. This enables a handler to deal with 55 ^^d the context in which it is thrown, such as being thrown 

all exceptions emanating from a given layer. on the client or server, and the context in which it is handled. 

Consider grouping by domains (Legal, Finance). How do you record the exception handling requirements? 

Consider grouping by subsystem During exception handling design there are several 

Consider common problems sudi as parameter validation, aspects to capture to achieve a consistent approadi: 

pre- and post-conditions ^ The set of exceptions to be bandied 

Consider the source (client or server). The set of responses to these exceptions 

FIG. 144 illustrates that groupings are not always exclu- The context in which the exception is handled; e.g. cHent 

sive. It IS possible to group some exceptions 14400, 14402, or server, batch or GUI 

14404 by layer and then domains within that layer. The set of exceptions to handle and their organization 

Benefits ^5 structure varies by project. Typically exceptions are orga- 

Simplicity, Simplifies handling logic by being able to nized into hierarchies to facilitate handling. The refuse to 

write a handler that deals with the base exception type. an exception may vary by exception type, the context in 
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which it was thrown, and the context in which is handled. 
Here are some examples of error handling decisions of a 
hypothetical project: 
"All exceptions thrown on the server, and not handled by 

the server logic, will be propagated to the client." 
"The current transaction is aborted if a server exception is 

not recoverable" 
"All Server exceptions derived from Excp will be logged 
if not handled by the server code. The last resort 
handler will ensure this." 
"GUI clients will display the error information in a splitter 
window" 

"Batch clients will send error information to Operations" 
These few examples demonstrate how context (Batch, 
GUI, Client, Server, last resort) can affect the handling of 
exceptions, and that even in a given context, the exception 
type may play a role in the haridling. In a real system there 
may be several other context and exception-type specific 
requirements. 

There are two common exception handling contexts that 
should be present in most systems. One is referred to as the 
Typical Response and the other is referred to as the Last 
Resort Response, The Typical Response is the error handling 
code intentionally added to handle exceptions. For example, 
carj5tart( ) is likely to fail due to being out of gas. The 
Typical Response may be to fill the tank and retry. The Last 
Resort Response is what to do when an exception is not 
handled (the Typical Response could not handle the error, 
such as a hole in the gas tank). Last Resort Response is a 
way of capturing what should be done when application 
code fails to handle an error. Recovery is usually not 
possible at this point but the handler may be coded to log the 
error and notify Operations of the problem. Wthout this 
response, systems may crash urmecessarily, or without indi- 
cating what happened. 

All these permutations of exception types, contexts, and 
responses need to be managed in order to maintain a 
consistent error handling approach. 

Therefore, use an Exception Response Table to capture 
the exceptions in the system, and the appropriate responses 
by context. What is important to capture is the exception, 
context, response, information; documenting the error han- 
dling requirements. 

The following table lists exceptions by category and type, 
with the typical and last resort response. Other contexts and 
responses are listed within these columns. The exception 
category field is optional but can help to organize exceptions 
by their source (application, architecture, . . . ) or hierarchy. 
This table can become quite packed with response informa- 
tion so a nomenclature may need to be developed to con- 
dense the information. The implementation section provides 
an example of this; Other ways of formatting this informa- 
tion are possible. 
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Exception 



Typical 
Re^nsc 



Last Resort 
Reqionsc 



Hierarchy Design. Analysis may show optimizations that 

can be made such as handling a subtree of exceptions 

with the same code, as the response is the same to any 

exception in the subtree. 
Interface Design. Discovery of interface requirements on 

the exception classes to support a particular response is 

another benefit. 
Handler design. Assists in exception handling design by 

identifying common responses that can be leveraged by 

the handlers. 

The table below shows an example of an Exception 
Response Table for a fictitious client/server system. Ttiis is 
followed by the nomenclature section which is customized 
per project. 



Name 


Typical Response 


Last Resort Response 


Architecbuc Framework 






Exceptions 






AaAssertionExq} 


C: N/A 


C: L, Popup(severe), 






Shutdown 


Assertion ^uie 


S: N/A 


S: UN, 






P(AaServerAaExcp), 






Shutdown 


AaExcp 


C: N/A 


C: N/A 


Base class for exceptions 


S: N/A 


S: N/A 


y^plication Exceptions 






CaBalaiKeExqj 


C: Popup(warn) 


C: L, Popup(wani) 


Account out of balance 


S: 


S: L,N, 




P(AaScrvcrAaExcp) 


P(AaServcrAaExcp) 


Nomenclature: 







Exception Category 

Excqition-Name 
Descrqition 

Exoqjtion Category 

Excqition-Namc 
DescT^tion 
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Benefits 

Requirements Traceability. Exceptions requirements are 
captured and managed through implementation. 



65 



Note: Abbreviations were used so that the table could be printed. The 
nomenclature section is only meant to serve as an example. 

Context 

C«Client 

S=Server 
Response 

N/A=not applicable; don't handle 

L=log error 

L(diagnostic)»log errors for diagnostic purposes only 
N«notify operations 

Optional°application, context dependent. Not required to 

be caught 
P«=pass exception to client 

P(<exception>)=pass given exception type to client, wiU 

be different from type caught 
Popup(wam)=display warning message 
Popup(severe)=display severe warning message 
Popup(retry)=display retry message 
Shutdown=release resources and shutdown gracefully. 
Exception Hierarchy discusses how to organize excep- 
tions. 

Last Resort Exception Handling describes where handlers 
should be placed to prevent a program fi-om terminating 
without warning. 

Polymorphic Exception Handler describes how to design 
and code exception handlers that reduce the impact of 
changes and the overall size of the error handling logic. 
Polymorphic Exception Handler 

FIG. 146 illustrates a flowchart for a method 14600 for 
minimizing the amount of changes that need to be made to 
exception handling logic when new exceptions are added. 
Exceptions are organized into hierarchies in a polymorphic 
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exception handler in operation 14602. A root of one of the 
hierarchies in which an exception occurs is caught in opera- 
tion 14604. The exception is instructed to rethrow itself in 
operation 14606. The rethrown exception is caught and 
identified in operations 14608 and 14610. A type of the 
rethrown exception is determined in operation 14612 and a 
message is outputted indicating the type of the rethrown 
exception in operation 14614. 

Single exception interfaces may he used as the roots of the 
hierarchies. Also, the polymorphic exception handler may 
handle each unique root. Further, an added exception may be 
organized into a hierarchy and handled by the polymorphic 
exception handler. As an option, handling behavior may be 
encapsulated in the polymorphic exception handler. As 
additional option, catch blocks may also be created to catch 
the rethrown exception. 

Large systems can be quite complex and require error 
management integrating disparate components and/or librar- 
ies (i.e. DBMS APIs, data structures library, middleware, 
etc) How can exception handling logic be written so that 
little or no dianges are required when new exceptions are 
added to the system? 

A software system using exceptions as the error handling 
approach may have to respond to a variety of exceptions. 
Handling each exception type on a case by case basis is 
cumbersome and expensive, both in terms of initial devel- 25 
opment and subsequent maintenance. In languages such as 
Java and C++, the mechanism to handle exceptions is to use 
try-catch blocks which look like this: 



fry 

// pcrfonn some work here 
catch (jEjBceptiDnTypeA& excp) 

// Exception A thrown.Handliiig logic heic 
catch (ExceptiDnI^eB& esq)) 
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// Exception B thrown. Handling logic here 
catch (...) 

// Don't know what was thrown, but still need to handle it. 
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This example ^ows only two exphdt exception types 
being handled but a system typically has several potential 
exceptions. If the development of the exception types is 
poorly designed the try-catch blocks can become quite large 
as they attempt to handle each exception. Imagine trying to 
handle, say, fifty more exception types, in several places, in 
the code. The error handling code expansion is exponential! 
FIG. 147 depicts a program 14700 (i.e., the exception 
handler of the present invention) with a few try-catch blocks 
14702. As more exceptions are added these blocks expand to 
handle each new exception. 

Another problem with exception handling logic is that it 
can be quite involved, such as logging the information to a 
persistent store, notifying Operations support, rolling back a 
transaction, etc. the example only showed one commented 
line to represent the code. Again, imagine each catch block 
requiring several lines of code. This logic may be repeated 
in each catch block. 

Taken together, varying exception types and potentially 
repeating and complex logic in the catch blocks, the devel- 
opment and maintenance efforts regarding error handling are 
going to be much more expensive than they need to be. 
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Therefore, stmcturc the exceptions into hierarchies, create 
an exception handler object that performs the catch block 
logic, and minimize the number of catch blocks required to 
support a given try-block. 

Exception Hierarchies organizes exceptions into hierar- 
chies and facilitates the design of exception handlers. Han- 
dlers can then be designed to handle the roots of hierarchies. 
This is much simpler than handling each exception type on 
a case by case basis. In custom development where the 
project has control of all code, a single exception interface 
can be used as the root. The more likely situation is some 
custom development and using third party libraries which 
may also use exceptions. In these cases, the exception 
handler will handle each unique root. 

Using an exception handler, versus custom logic per catch 
block, reduces the maintenance and development effort as 
the code is easier to read, there is less of it, and any changes 
that need to be made can be made in one place. 

The following code snippet shows the form of the try- 
catch blocks using the polymorphic exception handler. It 
may seem equivalent to the prior catch-block example but it 
is not. The first distinction is the type of exceptions handled. 
In this case, the roots of the exception hierarchies are caught, 
not the individual exception types. For this example there 
are only two exception hierarchies in the system, so only 
these roots are handled. What this means is that as new 
exceptions are added to the hierarchies, this code does not 
change, and remember, this code is in several places in the 
system. 

The second difference with this code is the encapsulation 
of the handling behavior in the exception handler. The 
handle method can perform arbitrarily complex logic behind 
the scenes, and if this needs to diange, is changed in one 
place. For example, if the current handling logic logs a 
message to disk and now needs to be extended to notify 
Operations personnel, this can be centralized in on place. 
The code as written does not need to change. 



toy 

// perfonn some work here 

catch (EzceptionRoot& excp) 

ExcpHdlr hdli; 
hdlr. handle(excp); 

catch CniirdPaityRoot& excp) 

ExcpHdlr hdlr, 
hdlr. handle(excp); 

catch (...) 

ExcpHdlr hdlr, 
hdlr.handle(); 



FIG. 148 depicts the same program 14800 (the polymor- 
phic exception handler) with smaller catch blocks 14802. A 
handler 14802 has been added which is consolidates the 

60 common code and the number of catch blocks has been 
reduced overall by making the handler responsible for 
handling each exception. The downside is that now the 
handler is subject to frequent change as exceptions are added 
to the system. The maintenance effort outweighs this disad- 

65 vantage. 

The examples have shown a single exception handler 
being used. In practice it is more likely that multiple will be 
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used. For example, the exception handler on a server may 
have different requirements or constraints than a client, or 
one client may be GUI based and display pop-up error 
messages, where another client is a batch program that needs 
to send notification messages to Operations. This can be 
handled by creating mtdtiple handlers or using the Strategy 
pattern to customize the behavior. 
Benefits 

Simplicity. Reduces development and maintenance effort 
required for exception handling 

Maintainability. Reduces impact of changes 

Robustness. Centralizes/Encapsulates handling logic 

Flexibility. Multiple handlers can be used 

The exception base class declares a method, rethrow, 
which is used by the handler to determine the real type of the 
exception. Another approach is to use double dispatch which 
may be ^ow in a future version. Below is an example of this 
interface only showing the essential detail. 



20 



II- 



//- Base Class of Exceptions 

U 

dass Esq) 
{ 

public: 

//- RcLhrow the exce{rtioii. Throw 
virtual void rethrow( ) const = 0; 

}; 

// 

//- Example Derived Class of Excqitions 

// 

dass Derived : public Excp 
{ 

public; 

virtual void rethrow ( ) const { throw *this; } 

}; 
//- 



//- Example Derived Cass of Exccptioiis 



dass SubDerived : public Derived 
{ 

public: 

virtual void r^hrow( ) const { throw 



}; 



this; } 
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When the exception handler is passed the exception from 
the catch-block all it knows it that it has a root exception 45 
type. For some projects this may be sufficient if the excep- 
tion interface is rich enough and all exceptions are treated 
the same. In other cases, exceptions may require specialized 
treatment. With the rethrow mechanism in place, the handler 
can create a try-catch block and have the exception rethrow so 
itself. The catch blocks are then used to catch the specific 
exception type. 
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-continued 



II- 



void ExceptionHandler::handle(const Excp& e) 

//- Rethrow the exception to get the specific type 

//- Note that catches are in the order of most specific to 

//- most general. 
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e.rethrow( ); 



//- Exception Handler 

// 



class ExceptionHandler 

{ 

public: 

ExceptionHandler( ); 

//- Handle the root exception 

void handle(const Exq)& ); 

//- Handle a third party lOOt 

void handle(const ThirdFartyExq)& ); 



Handle the exception 
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try 
{ 

} 

catch(SubDerivcd& cxcp) 
{ 

// Handle SubDerived 

) 

catch(Derived& cxcp) 
// Handle Derived 

} 

catch(.,.) 
{ 

// Handle e parameter here since nothing matched it. 

} ^ 

ExceptionHandler: :handle(const ThirdPaityExcp& e) 



25 



} 



// Handle based on TliirdPaityExcp inter&oe 

// Can't rethrow because ThirdPartyExcp doesn't support this. 

// Could use Rm if needed. 



Load Balancer 

FIG. 149 illustrates a flowchart for a method 14900 for 
distributing incoming requests amongst server components 
for optimizing usage of resources. Incoming requests are 
received and stored in operations 14902 and 14904. An 
availability of server components is determined and a listing 
of available server components is compiled in operations 
14906 and 14908. A determination is made as to which 
server component on the listing of available server compo- 
nents is most appropriate to receive a particular request in 
operation 14910. Each particular request is sent to the 
selected server component determined to be most appropri- 
ate to receive the particular request in operation 14912. 

Optionally, the determination of which server component 
is the most appropriate may be performed by allocating the 
requests on a round-robin basis whereby requests are 
assigned to consecutive server components by traversing 
along the listing of available server components. As another 
option, the determination of which server component is the 
most appropriate may also include calculating an amoimt of 
utilization that eadi available server component is currently 
experiencing. 

The amount of utilization of each available server com- 
ponents may be calculated based on current CPU utilization, 
kernel scheduling run-queue length, current network traffic 
at a node to the server component, and/or a number of 
requests currently being serviced. Also, a request may be 
rerouted to a different available server component upon a 
crash of the selected server component Additionally, the 
server components may be saved in a persistent store, 
wherein a check is made to determine whether a connection 
to a server component needs to be reestablished. 

In order to support scalability in a high volume distributed 
component environment, resources tend to be replicated. 
How can incoming requests be distributed amongst the 
available server components in order to optimize the usage 
of system resources? 

In a distributed system, server components provide func- 
tions and data that can be accessed by cUent components. 
Many identical copies of a server component can be running 
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on different platfonns in the system in order to support large roles in operation 15206. In operation 15208, a user context 

volumes of client requests. instance is created upon successful identification of the user. 

In order to make use of the system's scarce resources. The user context instance also includes information about 

some way of routing an incoming request to the best server including the roles. A request is received from the 

component available is required. In general, all requests take 5 to invoke a service on a component in operation 15210. 

a similar length of time to service. The component invokes an additional service of another 

FIG. 150 illustrates server components 15000 receiving component. The user context is queried for the information 

service requests 15002. about the user in operation 15212. The user information is 

Therefore, use Load Balancer to select the best server compared with an access control list for verifying that the 

component out of an available pool for the cUent to use. 10 ""^.^ component m operation 15214 The 

FIG. 151 illustrates a load balancer 15100 mediating the f^' '^-Z^^'T.! compared with an acc^ control bst 

reauests of FIG 150 verifying that the user has access to the additional service 

; . 1- * . ' * * J 1. .1. T J T. 1 of the other component in operation 15216. 

Incoming client requests are routed by the U,ad Balancer OptionaUy, all user interaciions may be logged as well. As 

to the best avjulable server component ^^^^ ^^^^ ^ ^^^^^^ ^ ^^^^ ^^^^ 

A number of possible strategies exist for deadmg which is access to actions that can be performed by the user based on 

server component is the most appropnate at a given point in an identity of the user and the roles associated with the user. 

The user context instance may also be passed along as a 

Round Robin — Allocate the received requests on a round- parameter of service invocations. Additionally, the service 

robin basis, whereby a list of the available server invoked may associate any objects created, updated, or 

components is created and, as requests are received, 20 deleted with the user context instance. As a further option, 

they are allocated by traversing down the list. When the context instance may also encapsulate security 

end of the list is reached, the next request is allocated certificates of the user. 

to the server component at the beginning of the list. security and auditing purposes, user information must 

Utilization Based— AUocate the received requests based maintained throughout a service's implementation across 

on the utilization that each server component is cur- ^5 multiple, distributed platforms. How can this original secu- 

rcntiy experiencing. The definition of utilization can be P^°^^^ ^ mamtamed throughout nested service invo- 

tailored to meet specific requirements or deployment ?^ distributed components? 

strategies. It may be based on a combination of current ^ mission-cntical systems require some form of security 

CPU utilization, kernel scheduling run-queue length, ^ t"^'"*^ capabihUes. These capabiUties restrict who can 

currem network traffic at that node, number of requests ^ use the system and ^at they can and cannot do and, in the 

currently being serviced, or any other factors particular ^ security breach or dispute, resolve who did what 

to the environment. ™ when. 

Benefits these capabilities, users must be identified, 

„ - T> J .1. t ^- . . 1 J associated with roles and granted authorization before any 

Performance. Based on the selection strategy employed, i« „ii • ♦ *• j 

^, ^ . J . .... . 35 operation proceeds. In addition, all user mteractions and 

the chent IS connected to the server component that is Jl„u^ „f -^^^ *• u 1 a 

best able to serve it results of those mteractions may be logged. On a user 

es e o serve 1 . interface, access to certain panels and controls are granted 

Scalabihty. As the number of users and requests increase, according to a user's role, 

processing can be distributed across the available In a distributed, component-based system, these complex 

resources. 4q requirements become even more difficult to implement. 

Robustness. In the event of the server crashing, the client l^pically, a client (or user) invokes some service on a 

can then ask the Load Balancer to provide another component. That component may invoke any number of 

server component for it to use. This can be extended additional services on any number of additional components 

still fiirther by federating Load Balancers and their to complete its designated task. These successive service 

associated server component pools. 45 invocations are a result of the initial chent request so the 

The following is the IDLthat was used to define the Load security profile that allowed the initial request must also 

Balancer allow all successive requests. 

FIG. 153 illustrates a component interaction diagram 
showing an interaction between a number of components in 

interfijce LoadBalancer a financial system. A user initiates an addStodc() service on 

( the Portfolio component 15300. To perform the addStock( ) 

Object gctservice ( ) service, the Portfolio must use the getStockPrioe( ) and the 

raises ( ArchitectureExccption ); deductFromAccount( ) services on the Market and Finance 

void register ( in aServerComponent ) components 15302^5304, respectively. This implies that a 

raises ( ArctutectureException k '^^ * . 

55 user who can access the addStock( ) service must also have 

permissions to access the getStockPrice( ) and the 

. deductFromAccount( ) services. This may need to be 

atx)rations checked by each of the distributed components within the 

Round Robin Load Balancing context of one logical service. In addition, auditing what has 

Utilization Based Load Balancing 60 been done, or perhaps requested to be done, adds another 

User Context common requirement that must be accounted for. A compo- 

FIG. 152 illustrates a flowchart for a method 15200 for nent servicing multiple chents must associate client requests 

maintaining a security profile throughout nested service with corresponding services invoked on business objects, 

invocations on distributed components. In operation 15202, This information must be persisted as each change is com- 

interconnections are provided between distributed compo- 65 mitted. 

nents each having nested service invocations. A user is Therefore, represent information about a user in a shared 

identified in operation 15204. The user is associated with User Context object. This object maintains a user's unique 
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identification that can be subsequently checked against a Reliable information access mechanisms in a multi-user 

resource's access control list (ACL). A User Context environment are a crucial, technical issue for ahnost all 

instance is created upon a user's successful, validated iden- systems that a user builds. 

tification to the system (usually through some "login" Most business information systems manage data which 

mechanism). After that, the system user interface can modify 5 must be saved in non-volatile storage (e.g., disk). The data 

itself to provide only the actions that can be performed by must hve, or "persist," between invocations of any particular 

that particular user acting in a particular role. Controls may application or program. Persistence is the capability to 

query the User Context and modify their own visual state as permanently store this data in its original or a modified state, 

needed (enable/disable, hide/show). until the information system purposely deletes it. Relational 

The User Context can also be passed along as a parameter jq databases, object databases, or even flat files are all 

of service invocations. All public, stateless services on a examples of persistent data stores. 

component should provide for a User Context to be passed This section discusses issues and approaches for devel- 

along as a parameter. The service being invoked can then oping an object-oriented persistence architecture, 

associate any Business Objects created, updated, or deleted Akey issue frequently encountered in the development of 

as a result of the service invocation with the User Context, jj object-oriented systems is the mapping of objects in memory 

One example of this would be a User Manager 15400 to data structures in persistent storagp. When the persistent 

associating a User Context instance 15402 with the Business storage is an object-oriented database, this mapping is quite 

Objects 15404 they are affecting. FIG. 154 illustrates a user straightforward, being largely taken care of by the daUbase 

mangerAiser context relationship diagram. management system. 

These associations can be used for auditing purposes, '° more common situation where the persistent stor- 
When a change to a Business Object is committed, a log age is a relational database, there is a fundamental transla- 
entry can be created tying the change with the user that problem or a so-called "impedance mismatdi". The 
triggered it. physical, logical, and even philosophical differences 
Benefits between a relational and object data storage approach are 
Common User Representation. One single representation 25 significant. Mapping between the two is hard. The architec- 
of a user and their access rights can be shared across all ^""^ ™"st, in this case, include mechanisms to deal with this 
areas of the system. impedance mismatch. 
Extensible Security. Because there is one source for the impedance mismatch is due to the following con- 
User Context various poHcies or strategies could be trasting features of objects/classes and tables: 
used to identity and authenticate the User within a 30 Identity: Objects have unique identity, regardless of their 
context. For example, it could encapsulate the User's attributes. Tables rely on the notion of primary key to 
certificates that allow more advanced security strate- di^inguish rows. While a relational DBMS guarantees 
gies to determine authorization. uniqueness of rows with respect to primary keys for 
Class UserContext stored in the database, the same is not true for data 
UserContext(Identifier identifier) 35 ^ memory. 

Identifier getldentifier( ) Inheritance: Hiis is a meaningful and important notion for 

String getName( ) classes; it is not meaningful for tables in traditional 

void setName(String newName) RDBMSs. 

void addRight(String acoessarea, AccessLevel level) Navigation: The natural way to access and perform func- 

void removeRight(String accessArea, AccessLevel 40 tions on objects is navigational, i.e., it entails following 

level) references from objects to other related objects. By 

Vector getRights(String accessArea) contrast, relational databases naturally support associa- 

boolean canCreateIn(String aocessarea) tive access, i.e., queries on row attributes and the use of 

boolean canReadln(String accessArea) table joins. 

boolean canUpdateIn(String accessArea) 45 The patterns in this section focus on problems and sohi- 

boolean canDeleteIn(String accessArea) tions associated with using a relational DBMS with an 

Qass AccessLevel object-oriented persistence architecture. 

static AccessLevel create( ) A key objective of a comprehensive object-to-rclational 

static AccessLevel read( ) persistence architecture is shielding the application business 

static AccessLevel update( ) 50 ^^g^c and developers from the relational structure. The 

static AccessLevel delete( ) benefits are a simplified environment for business 

boolean=(AccessLevel anAccessLevel) developers, reduced distraction with technical issues, and 

It is expected that the User Context will be passed from increased focus on the business object model and functional 

component to component. In this case the User Context will logic. However, in order to reap these benefits, a significant 

have to be defined using some sort of interface language 55 investment in architecture development is typically required, 

definition (IDL). The scope of a persistence architecture can range across 

Collaborations the following levels of tran^arency and automation: 

Permission Heavyweight, fully-automated, including the mapping of 

Policy the object model to the database schema and generation 

SecurityManager 60 of all the database access code. Variants of this archi- 

Logging tecture type may allow the customization of database 

Alternatives access code (e.g., for optimization purposes). 

MTS & EJB offer an environment that docs not require Lightweight mechanian which provides generic persis- 

the passing of the context with every operation. A container tence capabilities to business objects but delegates all 

as a set<context typo that provides a handle within the 65 database access to separately developed data access 

component for the methods to access the cached context. routines. In this case, the data access routines are not 

Information Services Patterns part of the persistence architecture per se. 
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Minimal persistence approach in which each business The logic to perform this conversion can vary from one 

object is directly responsible for database access attribute to another. Based upon the attribute type, a different 

Of course, there is a tradeoff between transparency, conversion must take place. In addition, special situations 

automation, and flexibility on the one hand, and architecture can arise where the same type of attribute will be stored 

complexity and development cost on the other. 5 differently in different situations. It is desirable to reuse this 

The patterns in this section solve several of the funda- logic; however, the solution must be flexible enough that the 

mental problems encountered in the development of an developer is not locked into one single translation for an 

object-to-relational persistence architecture, including the attribute type. 

mapping of classes to tables (Data Handler, Individual Therefore, use an Attribute Converter to translate data- 

Persistence), identity management (Object Identifiers as base values to object attributes and vice versa. 

Object), cachmg(Object Identity Cache), allocation of u . , *u c a. 

uv*' /ri ♦ IT -11 TV 1 « . • in ' t^G. 157 illustrates the use of an AtUibute Converter 

responsibihties (Data Handler, Piecemeal Retneval, Pfersis- ictaa* -u * icv/v^ • . j V 7^!,!? 

» « ♦ c \ n • * * ^t_* *\ J J 15700 to save an attribute 15702 into a database 15704. 

tent State Separatefrom Persistent Object), and data access ^'^tauax> x^fv>t. 

optimization (Multi-Object Fetch) and the mapping of basic knowledge of how to translate an attribute value to 

SQL types to object attributes (Attribute Converter). ^ persistent store is encapsulated in a separate 

In addition to providing persistence capabilities, reUable Attribute Converter object, 

information access mechanisms in a multi-user environment Th^ attribute's value should not be obtained directly from 

must support transaction semantics. As the real-life imple- attribute prior to saving it in the database. Nor should an 

mentation of all of the patterns in this section requires 20 ^^^^i^te be instantiated directly from the raw value obtained 

integration with transaction management frameworks, the persistent store. Values should be obtained or 

Persistence patterns should be considered and used in con- attributes created exclusively via an Attribute Converter, 

junction with the patterns in the Transactions section. It is reconunended that a different Converter be created 

Attribute Converter for each type of conversion required. This keeps the Con- 

FIG. 155 iUusU-ates a flowchart for a method 15500 for ^ verter's knowledge very ^dalized. As a result, the corn- 
translating an object attribute to and from a database value. bmation of Converters required to persist an entire object to 
A database is provided and a conversion process is deter- ^ persistent store is very flexible due to the modularity of the 
mined for converting an object attribute to and from a Attribute Converter objects, 
database value in operations 15502 and 15504. The conver- 30 Benefits 

sion process is ericapsulated in an attribute converter. A first Reuse. For some types of attributes, the conversion pro- 
object attnbute is directed to the attribute converter for eess can be rather involved. If this knowledge is 
conversion to a first database v^ue in operation 15506. A encapsulated in an Attribute Converter, it can be reused 
second database value is directed to the attribute converter fo, converting other attributes of the same type, 
for conversion to a second object attribute m operation 35 . . 

15508. Flexibility. If the conversion for a specific attribute needs 

A different attribute converter may be created for each ^ altered, simply substituting a different Attribute 

type of conversion of object attributes to and fiom database Converter wiU alter the behavior and not disrupt the 

values. In addition, the attribute converters may also imple- ^® appHcation. 

ment a common interface. Further, aU attributes of the same 40 Maintainability. Altering a single Attribute Converter can 

type may be directed to a particular attribute converter. ^ect several attributes in the system. For instance, if 

Optionally, a second attribute converter may be substituted the conversion of one specific type of attribute is 

for the attribute converter for altering the conversion of the identified as a performance bottleneck, altering the 

attribute. As an another option, the atuibute converter may corresponding Cbnverter can benefit a large part of the 

be altered for relieving a performance bottleneck. 45 system. 

Object attributes must go through some translation before Ideally, all Attribute Converters should implement a com- 

they arc written to and after they are read from some ™on abstract class or interface. This allows the architecture 

persistent stores. How can you isolate the translation algo- to treat aU Converters equally. The architecture need not 

rithm fiom the persistent object and the persistence mecha- know the specific translator class it is using, 

nism? 50 The interface may look something like this. 

When interacting with a relational data store, the attribute 
value doesn't always map directly to a database type. Other 

times, an attribute vahie maps to more than one database public btcrfece AttributcConvcrtcr 

type. ( 

For example, in an Object based system, an attribute with translate\%hieForDataStorc(Objcct anAttributc); 

a Boolean value is often converted fiom a Boolean object to j^J^^^^'"^"'-^'^'^ "^'"^ 

a "T" or "F" string before it is saved in the database. In } 

another example, a phone number attribute might be com- — 

posed of an area code (847), an exchange (714) and an ^„ ti, « * u t, • * 1 * w 1 * c^* 

extension (2731). TTiese three field mighl^ saved in thrce The first behavior, translateValueForDataStore, takes an 

separate database columnsor combined into one before they f into a Stnng that can be used m an 

are saved in the database. f^h s/atement. The second behavior, 

, « - translate ValueFromDataStore, takes a column name and 

HG. 156 Illustrates that an attrftute 15600 can't be saved jdbC result set as arguments. It then answers the attribute 

directly mto the persistent store 15602. ^ 4,3^,,^^ from the given result set. Each implementation of 

An impedance mismatch exists between the attribute and AttributeCoaverter must then implement both behaviors in 

the data store and a conversion must take place. their own specific way. 
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public dass BooIeanTianslator implements AttributeConveiter 



{ 



public String translate WueFoiDataStore(CX)ject anAttribute) 



{ 



Stiing value = mill; 
i£(anAttnbute null) 
{ 

if(((Boolean)anAttribute).boolcanVyuc( )) 



{ 
} 

else 
{ 



value = *"T*"; 



} 

else 
{ 

} 



} 



value = "*F"; 



value = "NULL"; 



retam value; 

} 

public Object translateV^ueFromDataStore(String aCblumn, 
java^LResultSet aResultSet) 

Boolean result = null; 
String value » null; 

value » aResultSetgetString(aCDlumn); 

if(valuexquaIsIgnoreCasc("T*)) 

{ 

result = new Boolean(true); 

else if(valuc.equalsIgnoreCasc(*'F')) 
{ 

result « new Boolean(falsc); 

} 

return result; 
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The Boolean Converter above knows how to translate a 
Boolean object to and from a character representation in the 
relational database. 
Collaborations 

Normalized Mapping — ^Ilie Mapper contains all informa- 
tion required to store an object in a relational data store. 
Attribute Converter can be utilized by Normalized Mapping 
to store the knowledge needed to properly translate attribute 
state values to and from the persistent store. 

De normalized Mapping — Denormalized Mapper is 
another pattern for mapping objects to a relational database. 
The Attribute Converter pattern could be used by Denor- 
malized Mapper to provide conversion between attribute 
values and database values. 
Alternatives 

Case Statements — Case statements aren't really a pattern, 
but they are an alternative to Attribute Converter. A case 
statement could be implemented in the super class to handle 
the translation of the data. 
Data Handler 

FIG. 158 illustrates a flowchart for a method 15800 for 
controlling data. A data retrieval mechanism is provided in 
operation 15802 for retrieving data from a database. The 
data retrieval mechanism also writes data to the database. In 
operation 15804, the data retrieval mechanism is encapsu- 
lated in a data handler. A request from a domain object is 
received for a retrieval of a portion of the data in the 
database in operation 15806. The data retrieval mechanism 
is utilized in operation 15808 to retrieve the portion of the 
data from the database. The portion of the data is passed 
through the data handler to the domain object in operation 
15810. 
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The data retrieval mechanism may be capable of being 
used by a plurality of domain objects. Also, the data retrieval 
mechanism may capable of being used by only one of a 
plurality of domain objects. Dependencies on the data 
retrieval mechanism within the data handler may also be 
managed via code generation. 

The data handler may physically partitioned into a com- 
ponent separate from the domain object. Optionally, the 
domain object may write attributes to a data stream. In such 
a case, the data handler may define an order in which the 
attributes are written to the data stream. Also, a row class 
may define the attributes in the same order as the attributes 
appear on the database. Further, the data handler may iterate 
over the attributes and may save them to the database. 

Business Objects in memory generally store and retreive 
their data members from some type of persistent store. When 
using Individual Persistence, how can we ensure that the 
retrieval mechanism used by the domain object is indepen- 
dent of the business logic? 

Individual Persistence assigns responsibility for data 
access at the level of individual domain objects. Each 
domain object or class can retrieve, update, insert, and delete 
its data from a persistent store independently of other objects 
or classes. This promotes encapsulation and reuse across 
business transactions. 

FIG. 159 illustrates the data retrieval mechanism calls 
being placed directly within the domain object 15900 (in this 
example SQL is inserted into the Account business object). 

When persistence is at the class level, it is typical to code 
the actual SQL, serialization, or CICS call directly in the 
class itself. In the example shown above, an "Account" 
object can contain the SQL needed to retrieve and save its 
state to the database. 

This approach can reduce the flexibility of the domain 
object, in that, changes to the access logic or the backend 
database must result in changes to the business object or 
class. How can we ensure that the business logic is inde- 
pendent of the data retrieval mechanism for such a class? 

FIG. 160 shows the interrelationship between a database 
16000, a persist 16002, and an account 16004. 

Business objects delegate their data retrieval mechanism 
to an appropriate handler. This Data Handler can be either be 
generic or specific to each type of domain object used. To 
minimize the impact of changes, dependencies on the data- 
base schema or data retrieval mechanism within the handler 
could be managed via code generation. In this manner, the 
physical data access is separated from pure business logic. 

FIG. 161 illustrates that the database retrieval mechanism 
is separated from the business object 16100 by encapsiilat- 
ing the logic within a data handler 16102. 
Benefits 

Loose Coupling of Data Access. The business object is 
independent of the database access logic and the back- 
end database. As a result, the method by which the 
domain object accesses the persistent store can be 
changed without impacting existing source code. 

Distribution. Data handlers can be physically partitioned 
into a separate component from the business logic. For 
example, the data handler could be on a data server 
component near the DB, while the business logic is in 
an application component. 

Multiple Data Handlers. Different strategies can be imple- 
mented based upon specific requirements. For example, 
on the chent we can use serialization to conmnmicate 
with the server; whereas the server can use standard DB 
access to conununicate with DB. 
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Support for Testing. Similarly, during testing, hard-coded DaU about a user is retrieved and packaged into a cross- 
data handlers can be created to return dummy data. functional data object in operation 16302 and 16304. A 
These can then be replaced at run-time or later in request for data is retrieved from one of a plurality of 
testing without mipactmg the code. business objects in operation 16306. lo operation 16308, the 
The foUovwng informaUon fooBes on the implementation 5 business object are directed to the data object such that the 
of the Data Handler pattern (TiMapper) and the separaUon business object retrieves the entire data object TTie business 
of the busmess domain objects from the data retneval object also selects the data from the data object, 
mechanism used on the project. r» ♦u i i • ^ • . v_ uaia uujci^i. 

FIG. 162 illustrates tte TiPersistenceStream 16200 and ^^^^ J?>c'^g??d;°^eg^ty mayuse aumformmechan 

TiMapper 16202 busmess object may retneve account, customer, and 

TiPersistenceStream and TiMapper ^° bill-related data from the data object. Also, the business 

Wthin the Rapid Batch Persist Service, objects save and ^^^^^ ^^^^ ^ ^P^*^^ themselves independendy of 

load themselves by writing to or reading from a Persistence ^ other. 

Stream. This isundertaken via the baseclass(TiPfcrsist)with Optionally, new business objects may take advantage of 

specialized streaming code created via the Creation Code existing data access routines. Also, each business object may 

Generator. As a result domain objects are only "aware" of ^ * uniform access architecture. 

how to stream themselves, and not how the data storage Create a data access architecture that supports reusable, 

mechanism works. independent business objects in the context of atomic, 

Tbe first attribute an object writes to the stream is its fimctionally-specific transactions. 

CLASS ID. The stream then expects the other attributes to A business unit of work, or business transaction, typically 

be put to the stream in the order defined by the mapper class 20 acts on multiple business entities. But for each individual 

(the data handler). This relationship between data handler entity, the transaction might only display and update a few 

and domain object is controlled via a row class, which data attributes. 

defines the attributes in the same order as they appear on the For example, accepting bill payment over the phone 

DB (this class is also created via the Code Generator). might use the account number, customer name, amount due, 

When the end of the stream is reached, the mapper class 25 date due, and credit card number. The transaction could 

iterates over the list of attributes within the row and saves therefore avoid accessing many attributes of the accoxmt, 

them via embedded Pro*C. When loading the reverse customer, or monthly bill entities. This might naturally lead 

happens, in that, the mapper loads the information from to a data architecture which only fetches required attributes, 

Oracle and then populates a row based upon the CLASS_ID based on the transaction's needs. 

pulled from the database. 30 Indeed, a traditional client/server program retrieves data 

TiMapper in a piecemeal fashion. In this case, the example program 

A Mapper for a class contains the columns(s) and table would typically allocate a single record to fetch and store the 

that the class will be written to, the type of the data and the required data items. Then, an "accept bill payment" data 

order that they will be read from/written to the stream. It also access module would fill this structure. This couples data 

reads and writes rows of data from the database. It generates 35 access to processing function, 

a where clause from the primary key information (PID). A FIG. 164 illustrates retrieving data piecemeal, 

database runtime context is obtained from the Transaction This traditional style of data access may seem flexible. 

Service (using the current implicit transaction context). It After all, developers can grab whatever data they need for a 

also contains the code to query for sequence ids, for classes particular business transaction. 

that use optimistic locking. 40 But such access is very unstructured. Different pieces of 

The mapper contains the data retrieval mechanism that a cohesive account entity, for example, scatter across mul- 

interacts with the Oracle database instance. As a result, if a tiple windows. Some windows will use the account's eflfec- 

different tedmology is used to interact with Oracle (e.g. tive date; others will not. 

stored procedures, embedded Pro*C, Method/3 Pro*C) only This also introduces redundancy. Retrieving the date 

the mapper class needs to change. 45 requires determining the correct database, Uble, column, 

^^ow and type declaration. Yet another developer who needs this 

A row contains the data to be written to a database row date, for a different data set, duplicates the effort. This does 

from a stream or to be written to a stream from a database not encapsulate changes, thereby raising costs for testing, 

row. It knows the column names on the table and knows the maintenance, and extension. 

order in which they are read from streams. so Moreover, each transaction must hand-craft its own 

TiMapperManager retrieval procedure. Creating the thousandth new business 

The mapper manager is responsible for creating mappers transaction would require creating a thousandth new access 

for a given CLASS_JD. Each type of mapper registers with module. Yet all data items would already have been retrieved 

the mapper factory when the shared object is loaded into by other modules. This style of data access is not reusable, 

memory (using the dynamic registration factory pattern). 55 Finally, business entities are typically less likely to change 

The mapper factory is a singleton read only object. than the transactions, or processes, which act on those 

The Factory pattern can be used to create the appropriate entities. For example, an enterprise might re-engineer its 

Data Handler for a specific business object This pattern billing fiinction. Regardless of the resulting process, the 

enables the data access method to be changed at runtime account, customer, and monthly bill objects would likely 

(e.g. batch mode, online mode or Request Batcher). 60 remain. This suggests that transaction-based data access is 

The Stream-Based Communication pattern can be used to brittle, 

stream the business object's data to the handler. The stream Therefore, data access should be organized around busi- 

can then be either forwarded to a Request Batcher or can ness entities, rather than transactions. Individual Persistence 

parsed and sent to database. packages data into cross-functional objects, rather than 

Individual Persistence 65 transaction-specific data structures. Each individual busi- 

FIG. 163 illustrates a flowchart for a method 16300 for ness object, instead of the window or application, manages 

organizing data access among a plurality of business entities. the retrieval of its data items. 
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A business object provides public methods for accessing, unstreaming, message compression, and error handling, 

comparing, displaying, and setting that data. Developeis can Moreover, business entities should support these capabilities 

therefore no longer plunder the persistent store, selecting through a consistent, polymorphic interface, 

data items at will. Instead, they must access their data For example, all business objects could respond to the 

through encapsulated, self-requesting business objects. 5 saveData message, to persist any changes. saveData could 

With this architecture, the example billing function fiist check, privately, if the object was even modified. Then, 

retrieves account, customer, monthly bill, and bill payment private CRUD flags, it could determine whether a save 

objects. translates into an insert, update, or delete. Finally, saveData 

FIG. 165 illustrates the manner in which the present could stream out the business object's attributes, based on a 

invention retrieves whole objects 16500. lo ^^^^ ^^y^"*- ^ transaction persists its business 

For reuse, business (Ejects should be able to request and ^'^^^ H^i^tmg over the ooUection, sending each 

updatethemselvesindependendyof each other. Separating ™^^i!^!Tf h u i , * ^ 

♦iT^ J * r ; J . t_* . ^ The architecture should also encapsulate the data access 

the data access for customer and account objects supports ^ ^ c v<Ep^>»*iai6 lus^ Kiaia a^A^sa 

;« r^u* ♦ u ^A J c a Protocols or products. For example, whether the business 

reusmg them m isolat on. Objects should therefore avoid ^^jects use a relational or object DBMS should be trans- 

exphcidy requesting other Imked objects, unless a formal is parent to calling programs. Tliis minimizes the impact of 

containment relationship exists. changes to the storage technology. 

FinaUy, separation of concern allows business objects to Individual Persistence naturaUy leads to multiple, smaU- 

remam blissfully unaware of the transactions which use grained request messages per transaction. Request Batcher 

them. A business object will not know which data items or solves performance problems with multiple network mes- 

services it may need to provide to its clients. Thus, the object 20 sages. 

must bring back all its data. Data H andler encapsulates data access code from business 

Benefits objects. This protects business logic from changes in data 

Reuse. New transactions can take advantage of existing access protocols and products, 

data access routines. For example, introducing a new Request Sorter handles referential integrity and deadlock 

business transaction, like perform credit check, would 25 avoidance in a uniform manner, 

use existing customer and account objects. Yet, these Multi-object Fetch 

domain model objects would already know how to FIG. 166 illustrates a flowchart for a method 16600 for 

update themselves. Therefore, the new application retrieving multiple business (Ejects across a network in one 

would build no new data access code. access operation. In operation 16602, a business d)ject and 

Maintainability and extensibility. This approach supports ^ * pliirality of remaining objects are provided on a persistent 

"fix in one place." Any changes to particular data ^P^^ receiving a request for the business object in 

elements only need to be changed, tested, and recom- operation 16604, it is established which of the remaining 

piled in one access module, that of the owning business objects are related to the business object in operation 16606. 

object. Th^ related objects and the business object are retrieved 

Uniformity. Both optimistic locking and referential integ- ^® persistent store in one operation and it is deter- 

rity (RI) are typicaUy defined at the business object retrieved related objects relate to die business 

level. For example, separate account and customer ^^^^ (^^ operations 16608 and 16610. A 

objects typically have their own locking attributes. In ^raP*^ °^ relationships of the business and related objects is 

addition, an RI rule usuaUy relates one entity to instantiated m memory in operation 16612. 

another, such as "all accounts must have a customer" ^ navigation pattern of accessing the business 

Organizing data access around business entities sim- ^^^^^ ^^^^ accessing relationships with the related 

plifies locking and integrity. Both can use a uniform "^^^^^ be used to retrieve the related objects. The 

medianism, implying that the architecture can hide relationships between the busmess and related objects for 

technical details. This avoids the hard-coding typical of instantiating the graph of relationships may also be deter- 

the transaction-based approach. ^™ ^ ^ set of target d?jects, and the 

HexibiKty. Whole object retrieval is extensible. It allows T relationship. AdditionaUy the establishment of 

atrans;ctiontoaskanobjectforanydata.niissupports t"""^ of the remammg objects axe related to the business 

maintenance and extension. A developer can ^fly ^ ! ^f^'T^'^^" t ^""^ 1"""^*^ 

changetheparticulardataitemsatransa^ionuses.But , <>t>J^ts ^^^^e to the busmess object and each other may ^ 

whole retrieval stiU guarantees that those items wiU '° P^^'^rf^ Z retnevmg the selected related objects 

already have been retrieved. For example, a We "^/^^ ''^"^ persistent store, 

release of die accept bill payment window could also T''''' ' ?! a? ^ '^J''^*^ ""'^ ^ 

display the social security number. Yet the data access l!^!!:!!^ 1??^.^' ? anodier opUon, a batch 

routines would need no modification. request may be sent to the persistent store for retneving the 

Each typical business class wiU support the standard ^^^^^^'f^^ o^J^^- i u • 

CRUD flag capabihties, of: ^[."^ "f""^^ ^^^^^ ™"^^P^^ busmess objects 

Create within a unit of work. How can the persistent objects 

involved in a unit of work be efficienUy retrieved? 

Retrieve ^ ^^^^ business object maintains associations to several 

^P^^^ 60 other business objects. A given unit of work needs to access 

^1^^^ a subset of the defined associations. In order to perform the 

Ihis access architecture is uniform across business enti- unit of work, the business object and the required subset of 

ties. The architecture can therefore standardize much of the associated objects must be retrieved &om persistent store, 

processing. For instance, the architecture can handle, across In Uie course of performing a unit of work, a set of related 
business objects: dirty checks, CRUD flag management, 65 objects needs to be accessed. Typically, one starts from a 

optimistic locking, referential integrity, security checking, "root" object and "navigates" relationships to access related 

commit scope, request formatting, object streaming/ objects. This process can be repeated on the related objects. 
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Ad entire graph of related objects can be accessed in this 
manner. A natural way to retrieve these objects is through 
lazy instantiation, i.e., objects are retrieved from persistent 
store as each relationship is traversed. This retrieval pattern 
typically requires multiple database/network accesses and 
can have serious perforaiaDce implications, especially over 
a WAN. 

Therefore, a mechanism is needed to perform the retrieval 
from persistent store in one access operation. This mecha- 
nism includes: 

Support for a declarative multi-object fetch statement 
which defines what is going to be fetched. This multi- 
object fetch statement does two things. It declares what 
is going to be fetched. It also declares how the objects 
that are being fetched relate to each other. 

Retrieval of the persistent data corresponding to the 
multi-object fetch statement. 

Instantiation of the graph of related objects in memory. 
Benefits 

Performance. Performance is increased by making a 
single trip across the network and a single database 
access to fetch several instances of objects that partici- 
pate in a transaction. The savings can be especially 
noticeable over a high-latency WAN. 

Continuity. Within the application code, the object navi- 
gation pattern of accessing an object and then accessing 
relationships from that object can still be used to access 
objects. 

Complexity. Requires more elaborate architecture than 
lazy instantiation. 

FIG. 167 illustrates an example of an implementation of 
the Multi-Fetch Object 16700. 

FIG. 168 illustrates the Fetching of a Household object 
16800 along with the other related objects using the multi 
object fetch results. 

FIG. 169 is an interaction diagram showing when the 
multi object fetch is not used. 

Note that if there is a large household, and each hobbyist 
in the household has lots of hobbies and interests^ several 
trips to the server will be made to fulfill this query. There 
needs to be a multi-object fetch specification that keeps 
enough detail to know what needs to be fetched and how the 
fetched object will relate to each other. Here is a structure 
that will capture that information. 
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HouseholdRelationshqJs[^^UMBER_.OF_HOUSEHOLD_RELA- 
nONSEflPS + 1] - {"Hobbyists", 0}; 
static char * 

HobbyistRelationships[^aJMBER_OF_IND^S^DAUAU_RElA- 

nONSFHPS + 1] - {''Hobbies**, "Interests", 0}; 

static MultiObjectFetchSpec Hol*yIntercstMofSpec(5] = 

{ HOUSEHOLD_CLASSID, HouscholdRelatioiiships }, 
{ HOBBYIST_CLASSID, HobbyistRclationships }, 
{ HOBBY_ClASSID, EmptyRelationship }, 
{ INTEREST_C1ASSID, EmptyRelationship ), 
{0,0} 



}; 
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There is a class MultiObjectFetch that performs the fetch 
and associates all of the related objects that have been 
fetched so that when these related objects are accessed there 
is no fiirther access to the database. The MultiObjectFetdi 
20 class uses the MultiObjectFetchSpec to determine how the 
objects fetched relate to each other. This implementation 
assumes that the persistent framework being used can fill in 
the relationship given a source object, a set of target objects 
and the name of the relationship. 
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class MtiltiObjectFetch 



{ 



}; 



public: 

MultiObjectFetch *MultiObjectFetch( 

MultiCX>iectFetchSpec *mofSpec); 
PeisistcntOtjject *fetch( ); 
RWOrdered •fetchRowB( ); 
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struct MultiObjectFetchSpec 



{ 



AxysOassId dassld; 
char **assodationName; 



This is a declaration of the multi object fetch using the 
example above with the Household, Hobbyist, Hobby and 
Interst. 



const HOUSEHOLD_CLASSID = 1; 
const HOBBYISr_CLASSID - 2; 
const HOBBT_CLASSID = 3; 
const INTEREST_CLASSID - 4; 

const NUMBER_OF_HOUSEHOLD_RElAnONSHIPS =• 1; 
const ^aJMBER_OF_JNDIVIDAUAL_RElA^ONSHIPS = 2; 
static char •EmptyRelationshipIl] «» { 0 }; 
static char * 



There is an assumption that the Household, Hd)byist, 
Hobby and Interest business objects inherits fi-om a common 
base class, PersistentObject. If the restriction on the house- 
hold is to bring back one Household, fetch( ) would used. If 
the restriction on the Household will bring more than one 
Household, fetchRows( ) would be used. The fetch and the 
fetcbRows brings back the Household objects(s) and the 
related Hobbyists, Hd>bies and Interests. 
Static i^roadi (Using Stored Procedures) 

A stored procedure would be written that would retrieve 
the Household object(s). Hobbyist objects related to the 
Household objects, H(*by objects related to the Hobbyist 
objects and the Interest objects also related to the Hobbyist 
50 objects. It is important that the stored procedure fetch the 
objects in this order since the multi object fetch spec 
declared that this is the expected order. These fetched 
objects would then be passed to the MultiObjectFetch object 
which would fill in all the relationships of the returned object 
using the fetch specification. 

Dynamic i^jproach (Dependent Requests/Pending Actions) 
The multi-object fetch can be pre-processed before send- 
ing the request to the database. Any objects that can be 
fetched ftom the cache will be fetched firom the cache. The 
remaining requests that cannot be satisfied from the cache 
will then be sent as a batch request to the database. This 
requires complex processing to determine if the cache can be 
used. This dynamic processing assumes that dynamic SQL 
will be used since it is not known at design time what objects 
will be found in the cache and what objects still need to be 
fetched from the database. 
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Dependent Request — ^used in dynamic approach Benefits 

Request Batcher— used in dynamic approach Performance. Objects are retrieved only when they are 

Batching Update — similar to bathing of fetches but used to needed. 

batch updates Caching and identity management. Object Identifiers can 

Relationship Stereotype — ^The setAssociation method is 5 be used to provide the unique id needed to implement 

called to fill in the relationships caching and identity management. 

Object Identifiers as Objects The object identifier (or OID) must contain enough infor- 

FIG. 170 illustrates a flowchart for a method 17000 for mation to uniquely identify the instance. This identifier 

implementing an association of business objects without could be a unique row id generated by a database, a UUID 

retrieving the business objects firom a database on which the lO generated by a utifity or a unique string generated from one 

business objects arc stored. In operations 17002 and 17004, attributes. It is generally desirable to have a different 

a business object is provided and an instance of an assod- ^^^^ ^XP^ of object, thereby creating a more 

ated object is stored on a database. An association of the type-safe environment. It should also be noted that OID's 

business object with the instance of the associated object is ^^^^ semantics. 

determined in operation 17006. In operation 17008, an 15 ^° addition, a mechanism must be available to retrieve 

object identifier is generated containing infonnation includ- objects given their OID. This can be as simple as a static (or 

ing the determination association which is necessary to ^*^) ^^^^^ such as getByld that takes the OID as an 

retrieve the instance of the associated object fix)m the aigument and returns the instance of the object. A more 

database. The object identifier is loaded when the business sophisticated approach would be to implement this and other 

object starts in operation 17010. A location of the instance 20 Persistence related methods in a generalized utiHty class, 

of the associated object on the database is determined in ^^^^ ^ ^ ™P*e example that illustrates the relationship 

operation 17012 from the object identifier and the instance between two classes using object identifiers. Please note that 

of the associated object is retrieved from the database in example is an extreme simplification. A useful imple- 

operation 17014. mentation of this pattern would exist as part of a persistence 

The object identifier may be used to provide a unique 25 frameworic that would include many additional methods and 

identity that is required for implementing caching and abstractions, 
identity management. Also, the object identifier may include 

a unique row identifier generated by the database, an idcn- 

tifier generated by a utility, and/or a unique string generated class Fooid 

from one or more attributes. As an option, different types of 30 public: 

business objects may be provided. In such a case, a different acccssois, constructors and destructors 

class of object identifier may be generated for each type of v^"^^ 

business object. As another option, the determination of a y 

location of the instance and the retrieval of the instance of class Fee 

the associated object may also include the taking the object 35 { 

identifier as an argument and returning the instance of the P^^^j 

„„„ : , , u* acccssors, constructors and destructors 

associated object. .^^i^ p^, gptByid(Fooid& id>, 

Most useful business objects have a relationship, or }; 
association, with other business objects. How should this class Bar 

association be implemented without having to read the 40 

associated object's state from the database? p^Q. getFoo( ) 

Most usefid business objects have a relationship, or { 

association, with another business object instance. return Foo::gctByid(Fooid); 

Traditionally, this relationship is expressed as a pointer or //^'^t^hc^is°'^ ^^^?pdcd°°' 

reference to the object. However, pointers (and references) 45 j auto_ptr ere is highly recommended, 

are memory constructs valid only so long as the object state private: 

exists in memory. When storing the object to a persistent Foold_J6old; 

storage medium (such as a relational database) these asso- 2i 

ciations need to be expressed in some other way. Likewise, ' " 

when the object is restored firom persistent storage, the 50 Collaborations 

associations need to be reinitialized since it is unlikely that Identity Manager — Uses Object Identifiers as unique 

the associated object will reside in the same memory loca- key's for storing persistent state objects. 

tion. If the associated object is stored in die persistent Persistent State Separate from Persistent Object — Uses 

medium, tiiis usually involves restoring it as well. This can Object Identifiers embedded in persistent state objects to 

become a long and expensive process if the association 55 eliminate coupling. 

graph corresponding to the restored object is large or com- Object Identity Cache 

plex. It is particularly undesirable if the associations are not FIG. 171 illustrates a flowchart for a method 17100 for 

even traversed by the appUcation. mapping of retrieved data into objects. An object is retrieved 

Therefore, implement the associations using object iden- from a data store and cached in operations 17102 and 17104. 

tifiers that contain the necessary information to retrieve the 60 A unique object identifier is assigned to the object in 

object if it is needed. These objects can then be loaded when operation 17106. The object identifier is mapped to a rep- 

the object is restored, eliminating the need to restore the resentation of the object in a dictionary in operation 17108. 

entire associated object In addition, since these object iden- When a request for a reference to the object is received in 

tifiers uniquely identify an object instance, they can be operation 17110, the object identifier of the object is 

used^assed in place of memory pointers. When the object is 65 retrieved from the dictionary in operation 17112. The 

needed, simply restore the instance using the object identi- requested reference is associated with the representation of 

ficr* the object stored in the dictionary in operation 17114. 
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In one embodiment, a data store may be accessed if the 
object i(kntifier is not found in the dictionary to retrieve the 
object so that the process may be repeated with the retrieved 
object. In another embodiment, a query may be performed to 
retrieve multiple objects. A check may be performed to 
verify that each object is already cached so that objects not 
already cached may be cached. 

Also, if an object in the cache has changed since read, an 
error may be raised if the object retrieved has changed since 
read and the object retrieved may be ignored if the object 
retrieved has not changed since read. If an object in the 
cache has not dianged since read, the object in the cache 
may also be replaced with the object retrieved if the object 
retrieved has changed since read and the object retrieved 
may be ignored if the object retrieved has not changed since 
read. Further, if a query is guaranteed to return at most a 
single object, the cache may be used prior to going to the 
data store by sequentially applying tiie function to each 
object in the cadie and implementing a predicate function 
which answers whether or not a given object satisfies the 
query. 

^thin a client context (e.g., a logical unit of work), the 
same object may be referenced more than once. How can 
object identity be preserved and redundant accesses to 
persistent store be avoided? 

(Although this pattern is not specific to relational 
databases, we will, for the sake of concreteness and clarity, 
describe the pattern in terms of an object-to-relational 
mapping.) 

Objects can be stored in and retrieved from a relational 
database. Aretrieval strategy that simply translates relational 
data into objects in memory will almost certainly result in 
the instantiation of multiple copies of the same object. 
Furthermore, such a strategy is inef&cient as the same data 
may be repeatedly and unnecessarily read from the database. 
This violates object identity and contributes to performance 
problems. 

Suppose the class Account has an association with the 
class Customer. Suppose the instance of Account ABC is 
associated with the instance of Customer 123. TTie following 
demonstrates multiple requests to Customer 123. 
Example 

customerl23=getCustomer(123) 
accoimtABC=getAccount(ABC) 
secondRefererenceToCustomerl23« 
accountABC.getCustomer( ) 
Note that customerl23 and secondRefererenceToCus- 
tomerl23 are the same customer. In this scenario, the desired 
behavior is to have the data store accessed once for cus- 
tomerl23. Also there should only be one instance of cus- 
tomerl23 in memory. Customerl23 and secondReferenc- 
eToCustomerl23 should reference this instance of the 
customerl23. 

Therefore, the mapping of retrieved data into objects 
should be mediated by an Identity Cache. FIG. 172 illus- 
trates an Object Identity Cache. 

Logically, an Identity Cache is a dictionary which, for 
each cached object, maps a unique object identifier to a 
representation of the object. Each object must be assigned an 
object identifier (OID) which uniquely identifies the object 
over the life of the system. 

The mediation mechanism works as follows: When a 
reference to an object is requested, the identity cache is 
consulted. If the object's OID is found in the cache, the 
requested reference is associated with the representation of 
the object stored in the cache. If the OID is not found in the 
cache, the data store is accessed. The object representation 
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that is retrieved from the data store is inserted into the cache 
and the requested reference is associated with it. 
Benefits 

Performance. Performance is improved for frequently 
accessed objects since they are only fetched from the 
database once. 
Identity Preserved. Object identity is preserved since 

objects are cached based on the objects OID. 
A dictionary can be used to implement the Object Identity 
Cache. The following points should be considering when 
implementing an Object Identify Cache. 

A query could be performed that returns multiple objects. 
Each object that is retrieved must be checked to see if it is 
already in the cache. If it is not in the cache it must be 
inserted. The following shows what should be done when an 
object is retrieved that is akeady in the cache to get is 
correctly inserted into the cache. 
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Object retrieved has 
changed since read 



Object retrieved 
has not changed 
since read 
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Object in cache has 
changed since read 



Object in cache has not 
changed since read 



Raise an erroL At 
commit transaction 
there will be an 
optimistic lock failure 
so it is better to raise 
it now. 

Replace the object in 
cache with the object 
retrieved since the 
retrieved object is 
newer. 



Ignore the 
retrieved object, 
the object in cache 
is newer and the 
changes should not 
be lost. 
Ignore the 
retrieved object, it 
is already in the 
cache. 
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If the object is not in the cache when the object is 
retrieved, a simple insertion into the cache can be done. 

If a query is guaranteed to return at most a single object, 
the cache may be used prior to going to the database by: 
implementing (for a given class) a predicate function 
which answers whether or not a given object satisfies 
the query 

sequentially applying the fiinction to each object in the 
cache. 

A multiple row query must go to the database unless there 
is a mechanism to indicate that the class is completely 
cached. This is applicable to static reference data. 

Life Time of cached objects can affect Cache size. If life 
time of the cache is associated with a transaction there will 
be no problem. If the fife time of the cache is associated with 
a longer lived entity such as a thread or a process, removal 
of objects fix)m the cache must be actively managed. Two 
conmaonly used strategies are reference counting and LRU 
purging. 

Collaborates with 

Object Relational Query pattern describes a mechanism 
for storing objects in a relation database. 
Object Identity 

Persistent State Separate from Persistent Object 
Used by 

Context Management 

Each Context (e.g., transaction, thread, etc.) owns an 
Identity cache which holds all of the objects in that context. 
Persistent State Separate from Persistant Object 

FIG. 173 illustrates a flowchart for a method 17300 for 
separating logic and data access concerns during develop- 
ment of a persistent object for insulating development of 
business logic from development of data access routine. A 
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persistent object being developed is accessed and a state of 
the persistent object is detached into a separate state class in 
operations 173Q2 and 17304. The state class serves as a 
contract between a logic development team and a data 
access development team. Logic development is limited by 
the logic development team to developing business logic in 
operation 17306. In operation 17308, data access develop- 
ment is restricted by the data access development team to 
providing data creation, retrieval, updating, and deletion 
capabilities. 

The business logic team may develop persistent objects 
that manipulate the state of the persistent object in accor- 
dance with business requirements. In one embodiment, the 
state may be implemented as a structure of values of basic 
data types. In another embodiment, the state class may 
contain member variables of lower data types including 
basic data types, extended basic data types with value 
semantics, other state classes, and/or vectois of the basic 
data types, the extended basic data types with value seman- 
tics and other state classes. 

Optionally, the state class may support data structures of 
arbitrary ^apes. Supporting classes may manipulate the 
state in a polymorphic fashion. As another option, the state 
may be further implemented as a class that contains key- 
value attribute pairs. The state class may also contain a 
keyed data structure containing attribute names and attribute 
values. Additionally, the state can also be asked to write data 
to a stream. 

When designing and implementing persistent objects, 
how do we effectively insulate the development of business 
logic from the development of database access routine? 

Given the use of a relational database as the persistent 
store, the scope of a persistence architecture can range 
across the following levels of transparency and automation: 
Heavyweight, fiiUy-automated persistence architecture. 
Including the mapping of the object model to the 
database schema and generation of all the database 
access code 

Variants of the above sdieme allowing the customization 

of database access code 
Lightweight medianism which provides generic persis- 
tence capabilities to business objects but delegates all 
database access to separately developed data access 
routines. In this case, the data access routines are not 
part of the persistence architecture per se. 
Minimal persistence approach in ^lich each business 

object is directly responsible for database access 
From a persistence perspective, no matter which of these 
approaches is used, development of the system and archi- 
tecture presents two distinct challenges to the development 
team. The first challenge is to accurately represent the 
business logic as a collection of business objects that include 
interfaces for performing the correct set of fimctionality. The 
second challenge is to be able to create, retrieve, update and 
delete (CRUD) records that represent the state of these 
business objects from the database in an efficient fashion. 

Data access and business logic are significantly different 
tasks both in their goals and development approaches. 
Consequently, except when a fully automated persistence 
architecture is used, it is often the case that two separate 
teams are responsible for the development of business logic 
and data access. If both teams work directly with the 
business objects, serious contention may result. Problems 
encountered in practice include: 

Changes to business logic that impacts the development 
(e.g., requires recompilation) of database access code 
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even when there is no change to the attributes of 
business objects. (Note: recompilation can be a prob- 
lem even if a fiiUy automated persistence framework is 
used.) 

Changes to the database schema can impact the develop- 
ment of business objects 

The data access team may unduly influence the design of 
the business objects, leading to a data-centric model 
and design 

The two teams' development schedules need to be in 
sync; slippage on one team can adversely impact the 
other team's progress 
Therefore, detach the state of the business object into a 
separate state class that can be agreed upon and completed 
prior to the start of significant development by either the data 
access team or the business object team. This class shoidd be 
nothing more than the raw data (preferably basic data types) 
used to represent the stale of the object TTie business 6bject 
contains all business logic and a reference/pointer to an 
instance of the respective state class. This allows the devel- 
opment of business logic and data access to proceed in 
parallel with the state class serving as a contract between the 
two teams. 

Using this approach, it is important to limit data access 
focus to providing CRUD operations (i.e., no business logic 
provided by stored procedures). The purpose of the data 
access portion of the application is to provide essential 
access to the data used by the business objets, and deliver 
this data in the most efficient way possible. Likewise, the 
purpose of the business object team is to develop business 
objects that manipulate the state of the object in accordance 
with the business requirements. Maintaining this separation 
insures there is no overlap between the development teams. 
Benefits 

Development Time. Data access and business logic can be 
developed in parallel reducing overall development 
time. 

Separation of concern. Data access remains separate from 
business logic, improving the understandability of the 
design. 

Testability. Business objects can be more easily devel- 
oped and tested based on data access stubs, thereby 
relieving the business object development teams from 
dependencies on the data access classes and the data- 
base libraries. 

Caching and identity management Separating the persis- 
tent state from the persistent object can be leveraged to 
aid in managing multiple class instances that represent 
the same entity (see the Object Identity Cache pattern). 
Object distribution. Separating the persistent state from 
the persistent object can aid in passing state in a 
distributed system. In cases where in is necessary to 
pass an object as an argument to a distributed method, 
it is more desirable from a performance perspective to 
pass the object's state as opposed to a remote reference. 
A new instance can then be created from the state, 
manipulated locally and then returned to the caller. 
The persistent state can be implemented in a variety of 

ways depending on the requirements of the system. They can 

roughly be described by the following 

Implement the State as a Structure of Values of Basic Data 

Types 

Each business object class has an associated struct. This 
is the most straightforward approach, although also the least 
flexible. With this approach, the business logic may need to 
manipulate lower level data types contained in the state 
object 



us 6,636,242 B2 



289 



290 



Supporting classes whidi need to manipulate the state 
object (in order to retrieve data from the database or pass the 
value between processes) need to be knowledgeable about 
the struct data type to manipulate it. In addition, copying the 
struct may be non-trivial if it contains dynamically allocated 
memory. 



struct State_Data 



{ 



long id; 
char code[8^ 
string value; 



Implement the State as a Class Containing Member Vari- 
ables of Basic Data Types 

1. Implementation using a "developer-friend!/* state 
class: A state class can contain basic data types (except 
char*), extended basic data types with value semantics 
(e.g., currency. String), other state classes, and vectors 
(not arrays) of all of the above. This does not, however, 
imply that the class is a flexible (dictionary-like) data 
structure. These state classes coiild/should all inherit 
from a common abstract base class which defines (but 
does not implement, at least in C-M-) a serialization 
protocol (Java is a different story than C++ because 
everything is serializable almost by default). 



class StatcOass 
public: 

virtual void read(Strcam inStream) - 0; 
virtual void write(Strcam outStream) - 0; 

class StateData : public StateQass 
{ 

public: 

virtual void read(Stream inStream); 

// implementation reads state data from stream, 
virtual void write(Stream outStieam); 

// implementation writes state data to stream. 

Private: 

long id; 
char code{8]; 
string value; 
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2. Implementation using an enhanced kind of the class 
described in (A) but which also happens to be a flexible 
data structure (in the sense that the same class can, 
similar to a dictionary, support data structures of arbi- 
trary shapes). 

This approach provides more flexibility since some com- 
mon behavior can be abstracted into a base class. In 
addition, supporting classes which need to manipulate 
the state object (in order to retrieve data from the 
database or pass the value between processes) can do so 
in a polymorphic fa^ion. Also, copy constructois and 
destructors can be used to handle dynamically allocated 
memory. 

Implement the State as a Class that Contains Key-value 
Attribute Pairs 

This is an alternative approach to the one listed above. 
Using this technique the state class would contain a keyed 
data structure (e.g. a dictionary) containing keys (the 
attribute name) and values (the attribute value). In cases 
where you want to copy the state or pass it to another 
process, the supporting code does not need to know the type 
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of the state object it is working with. State objects can 
simply be asked to read or write their data to and from a 
stream or string. While this offers a more dynamic solution, 
it should be noted that with this solution additional logic 
would need to be included in the persistent object to insure 
the validity of the associated state class. 

In all of these approaches, another important concept is 
the implementation of associations between objects. In 
general, the best approach is to store these as Soft Refer- 
ences to the other objects as opposed to actual pointers. This 
illuminates the need to load a large graph of objects when 
only one is needed, as well as easing the question of whether 
to implement a deep or shallow copy. 

Identity Manager Manages a collection of persistent state 
objects for a given class. 

Context Manager Used in conjunction with Identity 
Manager to maintain separate collections of persistent state 
objects for separate apphcation contexts. 

Lazy Instantiation: Restores persistent state object for a 
given object instance on-demand. 

Object Identity Cache: Caches persistent state objects 
referenced by persistent objects. 
Piecemeal Retrieval 

FIG. 174 illustrates a flowchart for a method 17400 for 
providing a warning upon retrieval of objects that are 
incomplete. An object is provided with at least one missing 
attribute in operation 17402. Upon receqit of a request from 
an application for the object access to the attributes of the 
object is aUowed by the application in operations 17404 and 
17406. A warning is provided upon an attempt to access the 
attribute of the object that is missing in operation 17408. 

The warning may include information on how to handle 
the missing attribute. An implicit transaction may also be 
called by the object upon the attempt to access the attribute 
of the object that is missing. In addition, an expUcit trans- 
action may be called by the object upon the attempt to access 
the attribute of the object that is missing. Also, the transac- 
tion may also include finding the attribute that is missing. 

When legacy transactions don't allow object or entity 
based retrieval, how do we retrieve useful objects? 

Object and component based projects designed and built 
from the ground up wiU likely have a well thought out 
component model and architecture where GUI widgets are 
linked or bound to domain objects. Data access (and 
retrieval) for these objects is organized around the business 
entity, rather than a transaction, and so data is packaged into 
cross-functional objects, rather than transaction-specific 
data structures. Each business object manages the retrieval 
of its data items. 

These domain objects provide public methods for 
accessing, comparing, displaying, and mutating data. 
Therefore, developers will only access data throu^ these 
eiKapsulated, self-requesting domain objects. (See Indi- 
vidual Persistence). 

For example a billing application that accepts biU pay- 
ment over the phone might use the account number, cus- 
tomer name, amount due, date due, and credit card number. 
With an Entity-Based Data Access architecture, the account 
17500, customer 17502, monthly bill 17504, and bill pay- 
ment objects 17506 will all be retrieved. FIG. 175 illustrates 
an Entity-Based Data Access System. 

This architecture is preferred if conditions allow, however 
legacy programs usually retrieve data through transaction or 
message based systems. These transactions often have two 
notable characteristics. One, a business unit of work or 
business transaction often acts on multiple business entities, 
and two, for each individual entity, the transaction might 
only retrieve and update a few data attributes. 
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Using the same bill payment example, a legacy system Transaction Service Patterns (1012) 

might utilize a * accept bill payment' transaction. Tlds trans- Transactions and LUWS 

action would require only a small portion of the attributes for A transaction is a set of business events that, coupled 

the account, customer, or monthly bill entities and so the together, accomplish a particular business function, such as 

data would be retneved piecemeal only as required by the 5 turning on gas service. Because the events are logicaUy 

tra^ction „ - . ^ . related, their data changes are logically related as weU. 

FIG. 176 dlustrates a Retneving Data Piecemeal System. Taken together, these data changes create a new, consistent 

In this case, the transaction would allocate a single record slate for the business model, 

(an 'accountPaymentData' 17600 structure as shown in the while a transaction is in process, the state of the business 
Figure) to fetch and store the required daU items. This jq model may not be consistent, so it is necessary to manage the 

structure would then be used to populate the business entire transaction from its point of origin to its point of 

entities. completion. Whether the transaction is successful or not, the 

As a result, domam objects are left mcomplete and point of completion will always result in a steady, consistent 

therefore unsuitable for use by all services. Hiis forces the state for the business model. For successful transactions, 
developers of services to know and understand the use of 15 data changes will be committed and the business model will 

transactions to retneve objects. reflect all new business data associated with the transaction. 

Therefore, when legacy circumstances dictate, retrieve por failed transactions, data changes will be rolled back and 

data piecemeal, on a transaction basis as necessary rather the business model will appear as it did prior to the start of 

than as complete business entities and develop mechanisms the transaction. 

to handle access and updates to missing attributes of piece- 20 To help manage the transaction &om point of origin to 

meal objects. p^jnt of completion, each transaction is organized through a 

By default, objects should return a warning when a single Logical Unit of Work (LUW). Ibis LUW manages the 

missmg attribute is accessed with no other means to retrieve business model and any of its subsequent data changes. 

It. This warning would simply let caUing applications know while both useis and internal exceptions can determine the 

that an attnbute is missing or unavailable. Hie calling 25 success of a transaction, the LUW handles the commit and 

application would then have to determine how to handle rollback operations. 

these mfesing attributes. _ FIG. 177 illustrates a Commit and RoUback routine 

A preferred approach to bandlmg missmg attributes would 17700. 

be to use multiple overlapping transactions. While, each As transactions become more complex and require a 

transaction might only populate a part of the object, the 30 greater scale of changes to the business model, the LUW 

transactions taken together assemble complete objects. trying to manage these changes becomes large and unwieldy. 

Tins use of overlappmg transactions could either be To simplify these transactions, the LUW is broken down into 

unphcit or explicit to the objects. An implicit transaction nested, more granular, logicaUy related units of woik caUed 

would be caUed by the object when a missing attribute is Secondary LUWs. Secondary LUWs are identical to LUWs 

accessed. This method of lazy rctneval may be preferable 35 except that their commit and roUback operations affect only 

because it is transparent to the calling appUcation. the business model of their parent LUW and are not per- 

An explicit transaction would be called by a tadc inde- sisted to a data store. Consequently, a secondary LUW must 

pendent of the object. Note however, that explicit transac- manage its data changes differenUy than its parent 

hons would either require that the task holds the object or piG. 178 illustrates Nested Logical Units of Work, 

that an object identity mechanism is used to find the existing 40 One method for managing changes to the business model 

object rather than create a new one. involves copying the model into the secondary LUW. 

In some cases, new transacUons can be created for the Another often simpler approach is to store both old and new 

exphcit purpose of retneving fuU or partial busmess entities. (or potential) values for all objects in the business model. 

This approach requires a thorough knowledge of the legacy Transaction Patterns 

system. 45 process of managing its business model, a LUW 

In other cases, the legacy code can be opened and the ^ often have to send messages to all business objects 

transactions modified to brmg back additional data. Care within the LUW. Examples of such messages include 

should used when doing so as legacy code is often fragile saveDataChanges, retrieve, or isDirty. Rather than hardcod- 

^d ixwrly documented. ing a call to each object m the model, the pattern LUW 

50 Context suggests using a bag (or collection) to hold all 

Legacy Reuse. The overwhehning benefit of piecemeal objects referenced by the LUW. Then, a single message can 

retrieval is that it enables reuse of legacy systems. be sent to the bag which will forward it to all djjects within 

Clients generally have a substantial investment in their it. 

existing systems and they will be hard pressed to Support for user multi-tasking can also present problems 

convert them to component based systems built on 55 for LUWs. Through multi-tasking, multiple LUWs will be 

objects. This pattern allows new systems to reuse running concurrently. Problems occur if the business models 

existing business logic through their transactions. of these concurrent LUWs overlap and the transactions 

Performance and Impedance. Objects based on transac- attempt to write to the same business object. A call center 

tions typically bring back only that data which is representative tiying to solve two customer problems during 

needed. The transaction is typically mapped direcUy to 60 the course of one call is one example of this scenario. The 

change that the user is trying to make. This improves Separate Models pattern helps solve this issue by assigning 

performance by reducing the number of network calls each LUW independent copies of their portion of the busi- 

and only bringing back data that is needed. ness model. This keeps one transaction from interfering with 

Individual Persistence organizes data access around busi- another, 

ness entities rather than transactions. 65 There are also several patterns that address problems 

Object Streaming handles the conversion of data from the related to sending transactions across the network. These 

structures received from transactions into business objects. patterns typically focus on minimizing network messaging. 
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When an LUW is called to commit, the transactioD will Additionally, the pointer may be a configurable field of 

assemble the necessary objects from the business model to the dependent request. The requests may also be reused 

send their data changes to the information services layer. independently of each other. In event another aspect of the 

This group of objects will include all new and dirty objects present invention, the dependent request may wait for the 

as well as any objects mariced for deletion. For each business 5 parent response at the server for minimizing network traffic, 

object, the transaction will likely have a corresponding During retrieval, one request may depend on the response 

request. If each of these requests were then sent to infor- ^^^^ another request. Nevertheless, ensure that a single 

mation services independently, a large number of network network message contains both requests, while using 

messages would result. To solve this problem, the Request Request Batcher. 

Batcher pattern batches all requests associated with a trans- 10 ^ business transaction typically acts on multiple business 

action together into one network message. On the other end ^f^^'. Consider an account mamtenance window which 

of the nttwork. Information services would unbatch the ^dits mformation tom accoimt, o^^ 

. , • * J * 1, home and work addresses. Given a unique account identifier, 

transaction requests and peisBt the data changes ^^^^^ transaction can retrieve all five objects. 

Another problem that may anse when mulUple requests once the account retrieves all of its data, it will know its 
are sent for a given transaction is deadlock. Deadlock occurs is unique customer identifier. The customer can then retrieve 

when two requests are trying to lock the same pair of objects. its own data, ^^ch includes the identifiers for the credit 

Each request locks one object and waits to commit until it profile and both addresses. Finally, the profile and addresses 

can lock the other. Therefore, each request will wait for the can retrieve their data. In this case, profile and address 

other to complete while neither is able to do so. The Request retrieval depends on customer data; customer retrieval in 
Sorter pattern works with Request Batcher to handle this 20 turn depends on account data. 

problem by sorting requests as they arc being unbatched by However, Individual Persistence requires that each object 

Information Services. A request is not allowed to proceed have its own, independent request module. That is, custom- 

until any dependent requests are completed. ers do not always need accounts to be retrieved. After a 

During retrieval, one request may depend on the response customer's unique identifier has been filled in — regardless 

data for another request. For example, a business transaction 25 whom — it retrieves its data independently, 

that tries to retrieve a customer when given a customer ID In theory, this independence is not an issue. The account 

will probably also want to retrieve the customer's address. could first get its data. After the customer's identifier was 

However, the transaction won't have the address ID until the filled, the customer could send its own request, 

customer is retrieve. Thus multiple network messages are 1° practice, however, sending multiple messages, in series 

required when one request is dependent on another. The 30 this, degrades network performance. Request Batcher 

Dependent Request pattem solves this problem by allowing 18000 provides a solution which bundles up requests into 

a batched request to indicate that it depends on another network message, thereby minimizing traffic. FIG. 180 

request. illustrates a Batching Retrievals and Dependency. 

As these patterns demonstrate, there is a high degree of This batching framework applies not only to update 

correlation between Transaction Services and Information 35 messages. For retrieval as weU, one overall, batch request 

Services. Many of these transaction patterns require an receives one batch response. Yet an individual batched 

understanding of Information Services patterns. Two such request may depend on the response data from another 

examples are Individual Persistence and Piecemeal batched request. The serial nature of the two requests must 

Retrieval. It is recommended that these patterns be read and ^ preserved, even while the requests actually go in the same 

understood prior to using Request Batcher, Request Sorter 40 batch, in parallel. 

and Dependent Request. Therefore, additional mechanisms ^ould allow a batched 

Dependent Request request to indicate that it depends on another request. If a 

FIG. 179 illustrates a flowchart for a method 17900 for business object does not have its primary key — or other 

allowing a batched request to indicate that it depends on the attributes guaranteeing a unique match— it becomes a 

response to another request. A group of business objects 45 Dependent Request Because a dependent cannot fetch itself, 

necessary for a transaction are provided in operation 17902. some other business object will inevitably have the neces- 

Logically-related requests received from the business sary foreign key. The dependent request will therefore 

objects are batched into a single network message in opera- register its dependency on this other object, 

tion 17904. One of the requests is a parent request. Received This object, the parent request, can have multiple depen- 

from the parent request in operation 17906 is a register that 50 dents. The aforementioned customer had credit profile and 

at least one of the requests is dependent upon the response address dependencies. This implies the need for an arbi- 

data. The network message is sent across a networic and the trarily large collection of dependent requests. A dependency 

requests are unbundled from the network message in opera- collection can even include requests for multiple instances 

tions 17908 and 17910. Upon receipt of a response to the of the same class. This was the case with two address 

parent request in operation 17912, data is directed from the 55 requests depending on the same customer, 

response to the parent request to the dependent request in FIG. 181 illustrates the Dynamically Setting Dependency, 

operation 17914. Received from the response to the parent Dependencies should not be hard-coded. Any business 

request is a response to the dependent request based on the object can register as dependent on any other object whidi 

received data in operation 17916. can provide the necessary data. 

The dependent request may not have a primary key. In 60 marmer, dependencies can be set at nm-time. This 

such situation, the response to the parent request may could happen while building the model, or as requests 

include the primary key for allowing the dependent request register with Request Batcher, 

to be responded to. As another option, the dependent request Benefits 

may also include a pointer indicating that the dependent Performance. This solution supports request batching for 

request is dependent on the parent request. In tins situation, 65 retrieving interdependent models, 

the pointer may be passed to the parent request during the Reuse. Because dependencies are not hard-coded, busi- 

step of batching the requests into the network message. ness objects can be reused independently of eadi other. 
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Loose Coupling. When a request dynamically registers its 
dependency, it need not know anything about its parent 
request. The dependent effectively says, "I don't know 



who you are, but I know that yom response data AccountPaymeiitActivity::saveDataChanges() 

contains my identifier." 5 // Propagate along the save message to aU business 

I>ependent Request woidd be irrelevant were it not for the // objects in my mw. 

"transaction impedance mismatch." This mismatch means tliis.getAccount( ).saveDataauiiiges( ^ 

that transactions no longer map one-tonone to access mod- [S'^'S^^'Biun^sl^^^ ^\ v 

ules. Individual Persistence is the approach which dicUtes this!^tBiUPa)Lnt( )'^^DataC3ianlS )i 

that eadi business entity have its own independent access lb } 
module. 



Request Batcher solves the performance problems of ^ retrieveData( ) message might also be required, if the 

sendmg mulUpk, small-grained request messag^ over a object model pre-instantiates obj^ before retrieving ^ 

netwoA. But the r^ultant si^e message must support ^^^^^ ^^^^ ^ ^ ^^^^^ S 

d^ndencies, with Dependent Request or a smular mecha- is dirty, replaces any changes with data originally from thedata 

* ♦ a u -* * 41. J lo^AA f Even without Individual Persistence, there are other com- 

FIG. Iis2 illustrates a flowchart for a method 18200 for *i_ • j ^ / i 

. 1 . 11 . - 1 • 1 .7 mon messages the window may want to send. For example, 

sendmg a smgle message to all objects in a logical imit of j- . u * * * • « j * i_ . u . T . 

,f r . distnbuted objects typically need to be told when their 

work. Agroup or busmess objects necessary for a transaction 20 „^„^„, /-tikji . *u « i 

^Tj J J J-'. 1 • 1 , * memory can be reclaimed. COM+ uses the well-known 

are provided and managed in a logical unit of work m „ *l j i n r/ \ u • i 

operations 18202 and 18204. A receiver is created which rARRA'^^'^Sr^ t''"^, ™P'^"'^"'^''°'^ °^ 

communicates with the business objects in the logical unit of '^^^ >" ^f'^^, ?"f^ * 

■t • ^o^Af », • i- sage that would also need to be sent to the busmess obiects, 

worie m operation 18206 Upon receiving a message for the saveDataChanges( ) propagation above. 

^^'Ihfnr. ^ " Dirty Flag provides anothir «aiple. Here, the window 

^ ? «l^«ed to the receiver m operation accumulates the results of dirty checking, as follows: 

1S210. The receiver also forwards the message to each of the / &» 
business objects in the logical unit of work. 

Several groups of business objects necessary for a trans- 

action may also be provided with each group of business 30 AccountPaymentActivity:dsDirty Q { 

objects being managed in a separate logical unit of work. // Return true if any single business object in the LUW is dirty. 

Also, a separate receiver may communicate with each group , ^ .r. - ^-^^ 

ru-^ A *!. *• .t-.L* (this.getAccount0.isDiityO or 

of objects. As another option, a request batcher m commu- this.getCustomer0.isDirtyO or 

nication with the receiver may also be provided for batching this.getMonthlyBiil().isDirtyO or 

requests from the business objects for delivery. In such an 35 this-gctBaiPaymentQ-isDirtyO); 

embodiment, the request batcher intercepts the requests ^ 

from the business objects and holds the requests until told to 

delivertherequestsby an activity associated with the logical This bard-coded approach, although straightforward, is 

unit of work. both tedious and error-prone. It is tedious because business 

Optionally, the receiver may hide technical details includ- 40 developers shouldn't have to deal with technical issues like 

ing details of persistence and garbage collection from busi- dirty checking or distributed garbage collection. They 

ness developers. As a further option, the business objects should focus instead on business-specific processing, 

may be distributed across a network. Also, the receiver may Moreover, this is error-prone because it can be difficult to 

distribute the message to each of the business objects across detect if the developer makes a mistake. For example, a new 

the network. Additionally, the logical unit of work may 45 requirement could make the window display address infor- 

optionally be modeled as an object in software. mation. In addition to repainting the window, the developer 

y^lications often need to send technical messages, like would also need to modify their hand-coded methods. But 

saveDataChanges( ) or release( ), to all business objects in the developer might forget to update the isDirty( ) or release( 

an LUW. Do this in a consistent manner and hide technical ) methods. Such errors can be difScult to locate. (Readers 

details from business developers. 50 who have debugged memory leaks will certainly agree.) 

Consider an Account Payment window, which displays Instead, an architecture mechanism should encapsulate 

information about an Account, Customer, Monthly Bill, and the propagation of these technical messages. When a mes- 

Payment. This window occasionally needs to send generic, sage needs to be forwarded generically, to all objects in an 

technical messages to all business objects within its LUW. LUW, the architecture should handle it. Such a capability 

This messaging has nothing to do with the window's 55 would free business developers from worrying about these 

application-specific behavior. In fact, the other windows in technical details. FIG. 183 illustrates a Hand-crafted Mes- 

the system need to send the same, generic messages to their sage Forwarding scheme. 

LUW business objects. Although the business objects Therefore, an architecture "bag" will represent the busi- 

receiving these messages differ from window to window, the ness objects in a particular LUW. This bag, or collection, 

messages remain the same. 60 will hold onto each business object. Then, when the bag 

In addition, this messaging typically has an arbitrary receives a message like saveDataChanges( ) or release( ), it 

order. All that matters is that all business objects eventually simply forwards the message to each member business 

receive the same message. object. 

For example, the window might use Individual Persis- FIG. 184 illustrates a Generic Message Forwarding fea- 

tence. Then, when the user decides to save the window, all 65 ture. 

business objects receive a message like saveDataChanges( ). Each LUW must have its own bag. This enforces the 

The resultant pseudo-code would look like: Isolation property (of ACID) for LUWs. That is, one LUW 
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should not alFect another LUW. For example, if the Account 
Payment and Account Services activities have separate 
LUWs, they will correspondingly have their own bags. 



Then, calling saveDataChanges( ) on the Account Payment AbstiaciLUWActivity:saveDatoChangesO { 

activity wiU forwari saveDataChaog«< ) to only'Ise 5 '^^Zf^.Tr^rC^i::^,, 

business objects owned by Account Payment. // know about this method. 

The bag also helps ensure the Atomicity property (also of this.gctLUWContextO-savcDataChaiigesO; 

ACID) for LUWs. It provides a single, atomic interface into I 

the multiple business objects of the LUW. By design, it ^ _ 

ensures that all business objects receive the same architec- lO This assumes that business objects were put into the LUW 

ture messages. Context in the first place. The context object can be passed 

Thus, the scope of a bag is an LUW In addition, a bag in when instantiating an object, tran^arently by the persis- 

provides contextual information for the LUW — i.e., which '^nce and streaming frameworks, etc. 

business objects that LUW uses. The architecture bag there- ^ LUW Context can collaborate with a Request Batcher, 

fore models the LUW Context, and will be named as such. 15 ^ requests are batched for transmission to the data store. 

Benefits Rather than storing the batcher globally, each context and 

Encapsulation. LUW Context hides technical details of ^^^^^^.'^odel'^anhave its ov^ manager. TTiis allows multiple 

^^L:^*^„^ 11 * 4^ i_ • domam models, m multiple contexts, to send transactions 

persistence garbage coHecUon etc from business simultaneouslybut indep^ndendy. Then, whenever a busi- 

hTr'l w'^T ness object requests an^ or upda^ its request will be 

hide this framework, m entirety, from busmess logic. 20 intercepted by the model's particular Request Batcher. Hie 

Robustness. This approach guarantees that each business batcher then holds these requests imtil the activity — which 

object in the LUW receives forwarded messages. There owns the LUW — teUs the batcher to send them, 

is no longer the chance of a developer forgetting to The LUW Context holds onto all domain objects in a 

include a particular business object in a group message. particular model. It can therefore collaborate with an Iden- 

y^lication Maintainability. As the application require- ^ Registration Manager, to enforce object uniqueness 

ments change, the set of business objects in an LUW particular context 

can change without impacting the generic, LUW code. T°^. Potential Variables pattern, which provides local 

For example, a future version of t£ Account Payment '^^'JL'^Tf^ ? ^^'^^^^ ^^j^^ SoinXions 

window could also display Address information. This handbook. If local LUWs use this approach, then LUW 

introduces a new business object into the LUW. Yet it ^ ^ ^ 

would not require updating saveDataChangesT ), or t u* 

release( ) methods, as it would have previously. pattern, every time a business object sets an 

nprfr,rr«.«^^ T I Tw f w A \' 11 - attrfbute, tfac vanaWc must bc checked. Hic LUW Coutext, 

Periormance. LUW Context can dramatically improve „^ ^, „ • , • . ^ ... 

_r - J* . -t- . J ^ ""1/1 v/T *, as mtermediary, can provide a simple pubhc mterface which 
performance m a distnbuted environment. By nature, it a • *u i_ ^i^^^*"^ wm^u 
r » c r^. ^ iiaiiujL,, II. 35 supports setting and queryinc the phase variable, 
batches up messages for a group. This can reduce Request Batcher ^ ^ ^ ^ 
network messaging. ^ . ^ FIG. 185 illustrates a flowchart for a method 18500 for 
For exMiple consider a search wmdowwhidi hasinstan- batching logical requests for reducing network traffic. A 
Uated 30 busmess objects. Releasing those objects, if g^up of business objects necessary for a transaction are 
^e messages were sent mdependently, would require 40 provided and managed in a logical unit of work in operations 
30 iKtwork messages. However, with LUW Context, a 18502 and 18504. In operations 18506 and 18508, logically- 
single message can go from the cfient to the server. related requests received from the logical unit of work are 
Then, withm the server executable, the LUW Context g^uped into a single network message which is then stored, 
forwards leleaseO to the 30 member objects. This is far The message is sent in operation 18510 upon receiving an 
less cosUy than usmg the networic for that messaging. 45 order to send the message 

Because of this message batching, some readers may OptionaUy, update and retrieval transactions may be 

oonfiise LUW Context with Request Batcher. It is true grouped into a single network message which is stored. The 

mat both reduce the number of network messages. message may be sent upon receiving an order to send the 

However, the foraier is concerned with supporting a message. As another option, the requests from the message 

family of genenc, architecture messages, like isDirty( ) 50 may be unpackaged at a point across a network and data 

and refresh( ), on a smgle atomic object. The latter is changes may be persisted. In a further optional embodiment, 

concerned with groupmg database requests into a responses to the requests may be received and the responses 

physical package, for un-batchmg at the server. may be bundled into a reply. In one embodiment, the 

Although both have similar principles and requests in the message may be sorted. In such an 

charactensUcs, they solve different problems and are 55 embodiment, the requests in the messages may also be 

implemented differently. separated into submessages. 

Architecture Extensibility. LUW Context models the When domain objects request themselves, minimize the 

LUW as an actual object in the software. Any other impact of network traffic. 

architecture processing which executes on a per-LUW Individual Persistence assigns responsibility for data 
basis can also be coded there. (See the Related Patterns 60 access to individual business objects. Then, each business 
section for examples.) object can retrieve, update, insert, and delete its data from a 
This pattern seeks to hide the message propagation from persistent store independently of other objects. This pro- 
business logic. In fact, messaging to an LUW Context can be motes encapsulation and reuse across business transactions, 
hidden completely in an architecture superclass. Previously, FIG. 186 illustrates the manner in which the present 
saveDataChanges( ) would've been coded specifically in 65 invention sends requests 18600 independently, 
each concrete activity class. LUW Context allows it to be Thus, an LUW which uses multiple business objects wiU 
abstracted, as in: correspondingly have multiple requests. This might suggest 
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that each independent request communicate independently A request may also not be allowed to proceed until all 

with data access services. Then, each logical request would dependent requests arc completed. A plurality of Uansac- 

translate into its own physical, network message. tions may each use the same sorting rules for preventing 

Every network message imposes a certain amount of deadlocks. Optionally, the class represented by each request 

overhead, independcndy of its contentsor length. This 5 may be determined so that the sorting rules may be based on 

implies that multiple, small-grained messages have more aclasstype.Asanotber option, the sorting rules may include 

overhead than a single, large-grained message. Many referential integrity rules which ensure that references 

networked-constrained environments cannot tolerate this between two relational tables are valid. In such a situation, 

additional overhead. Such environments should minimize a linear ordering of requests may also be created based on 

the impact of this network traffic. lo the referential integrity rules. The numbering of the position 

Therefore, a high-performance transaction should batch of the request in the Hnear ordering may also be the weight 

its logical requests into a single network message. Moreover, of that request so that requests with lower weights are 

a framework should handle this packaging, transparendy to processed before requests with higher weights, 

application logic. In an update transaction, order requests for referential 

FIG. 187 illustrates a manner in which the present inven- 15 integrity and deadlock avoidance, 

tion registers requests. Referential Integrity 

A Request Batcher 18700 object will group logically- Referential Integrity (RI) ensures that references between 

related requests. All requests will register with this coordi- two relational Ubles are valid. That i&, foreign keys in one 

nating object, rather than sending themselves inmaediately table must refer to existing primary keys in another table, 

and independently to their server or database. The batcher 20 For example, RI rules could require that all accounts have a 

will then store these requests together, until told to send customer. Then, values in account.cust_id would need 

them as a xmiL This batdiing applies equaUy well to update matching values in customer.cusl^d. 

and retrieval transactions. Mission-critical RDBMSs can enforce RI at run-time. 

A corresponding Request "Unbatcher" 18702 on the Then, if a modified foreign key docs not match an existing 

server will unpackage the bundled network message. 25 primary key, the database prevents the update. 

Finally, this Unbatcher will bundle the network refuse and Continuing the example, a transaction may insert a new 

send it back to the Request Batcher. customer and its new account. If the transaction inserts the 

Benefits account first, account.cust__id will refer to a non-existent 

Performance. Sending a single message of multiple customer. The RDBMS will raise an error, thereby failing 

requests, as opposed to multiple messages of single ^ transaction. Instead, the account request should run after 

requests, improves communication performance. the customer request. 

Dynamic. Batching and sorting requests is transparent to Deadlock Avoidance 

the requests themseh^es. Requests do not know that a Even without RI, request ordering remains an issue. 

particular transaction contains them. This dynamic Imagine a transaction A orders customer before account. 

relationshipallowsanytypeofrequesttobepartofany Conversely, a concurrent transaction B orders account 

transaction at run-time before customer. A will request a lock on the customer table, 

Scaleability. In an asynchronous or multi-threaded 7»>fle Bwm request a lock on the account table^Am^^ 

environment, an appli«tioo could use multiple Request ^ ""T ^ ^ 

Batchers. For exie, each LUW could h^ve ite own ^ "'^^'''1:^^ . ^ "^^^^ '%T^'°T^°^^- . 

batcher. A batcher ^eds to store state while building ^"^ transactions will deadlock. Many transacUon- 

the batch, as requests n^gister. Using multiple instance! V'^^S. systems would simply fed both transacUons. 

fecilitates relation Sm; and seeding ot multiple tS transactions may otherwise have 

batches simultaneously. Users can then multi-task Traditional An roach 

while other, time-consuming requests process in the ^ ^H'proac , , ^ „ , 
background 45 Traditionally, transactions have hard-coded deadlock 
. * avoidance and RI. Each transaction has called its own update 
This sunullaneity can also be supported with one, multi- module. Each hand-crafted module has ordered multiple 
threaded batcher. In this case, each request registers SQL statements, according to these rules, 
along with its unique transaction id. However, with Individual Persistence, a transaction no 
Centralization. The batcher has visibility over all requests 50 longer maps to a centralized module. Instead, independent 
in the LUW. This provides a centralized point to sort requests register for the transaction in an ad-hoc manner, 
these requests, thereby supporting referential integrity FIG. 189 illustrates an Ad Hoc Registration feature, 
and deadlock avoidance. Moreover, an account has no hard-coded "knowledge" 
Request Sorter that it should persist after a customer. This independence 
FIG. 188 illustrates a flowchart for a method 18800 for 55 provides flexibihty any business object can request an 
sorting requests that are being unbatched from a batched update without concern for other business objects. A frame- 
message. A group of business objects necessary for a trans- work which constrains the request order must support this 
action are provided in operation 18802. Logically-related flexibihty. 

requests received from the business objects are grouped in Therefore, an update transaction shoidd sort its requests 

operation 18804. Sorting rules and/or sort weights are 60 before sending them to the data server. The sorted result will 

obtained in operation 18806 and, in operation 18808, the conform to RI rules. Then, across update transactions, all 

requests in the message are sorted and placed in a specific customer requests can appear before aU account requests. In 

order determined from the sorting rules and/or the sort addition, every transaction will use the same sort algorithm, 

weights. The sorted requests are batched into a single That will prevent deadlocks. 

message which is sent to a data server where the requests are 65 Multiple requests can no longer send themselves directly 

unbundled from the message in the specific order (see to the server, in an ad hoc fashion. Instead, they must register 

operations 18810, 18812, and 18814). with a centralized object, which can sort them first. A 
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centralized Request Sorter will order multiple requests copy of the commoa business object is created for each of 

before finally sending the transaction. the logical units of work such that the copy of the business 

FIG. 190 illustrates a manner in which the present inven- object for one logical unit of work becomes a separate 

tion sorts requests by weight. instance from the copy of the business object for another 

The sorter 19000 will have visibility to sorting rules, or 5 logical unit of work. Each copy of the business object knows 

even weights, to determine this order. The rules can typically the context of that copy of the business object in relation to 

be based on the class type. Before sending the transaction, the associated logical unit of work. Upon receiving a request 

the sorter can ask each request which class it represents. In to make changes to a copy of the business object of one of 

this manner, the sorter can re-order the requests appropri- the logical units of work in operation 19106, that particular 

ately. lo copy of the business object is changed while the other copies 

Benefits of the business object are not changed. It is then verified in 

Separation of Concern. This sorting pattern hides the operation 19108 that only one copy of the business object 

technical details and complexity of RI from business has been changed and the common business object is 

logic, implications avoid hard-wiring customized RI updated in operation 19110 based on the change to the copy 

rules for its transactions. 15 of the business object. 

MaintainabiUty. RI rules can easily be changed without Abusiness object may optionally be passed as a parameter 

impacting appHcation code. Granted, this does not from one context to another. In such case, a context copy of 

happen frequenUy in production. busmess object may be created which includes a dupli- 

11 u*v* T-u ■ n 4 c ^ -1 cate of the original data and excludes a context variable. As 

Reusabihty. The genenc Request Sorter uses universal ^„ ** u *t. 

«r„, • 1 1 u 1 20 another option, an exception may be thrown when an 

sortmg rules, or weights. These rules arc global across ^ :^ \„^a \ « ♦ / u - u u • 

U - \m *i-i t._i attempt is made to create a copy of a business object bems 

busmess processes. Moreover, the rules are based on u au i - i •* t j r *i. i - i ? 

• ui u. • u- ^ r altered by one logical umt of work for another loaical umt 

existmg, reusable business objects. Therefore, new of work. 

apphcations can reuse the sorter, as well. u - u- * i l . . .t. 

, ML -f w/. ^ The busmess object may also be sent to another context as 

Visibihty. If RI enforcement is distributed across appli- at least one of a single focus of a window that is being 

cation logic, it can be difficult to get a complete picture created and a parameter in an explicit parameter-passing 

of the referential rules. Request Sorter centralises those mechanism. Additionally, the copies of the business objects 

rules (i.e. weights) m one, visible place. may be created &om a same retrieved data stream. As a 

A complete, Imear oidermg of all domain classes can be farther option, receiving a request to make changes to a copy 

created, based on the RI rules. Each class wiU have a unique 30 of the business object of one of the logical units of work and 

position m the ordenng. This position is the cW weight for changing that copy of the business object may further 

the sortmg algorithm. Requests for domain objects with include the broadcasting of the change to the other logical 

lower weights will always appear before requests with units of work. 

higher weights. Support multiple business LUWs within an MVC-based 

For example, consider the ordermg: 35 architecture. Manage diese LUWs concurrently yet 

27. , . , separately, thereby preserving the Isolation property of 

28. Customer ACID. 

29. MeterRead Multi-tasking allows the user to complete several different 
30 Account business functions independently of each other. Those func- 

* 40 tions which are business LUWs must process concurrently 

* ^ yet separately. For example, a user could establish a new 

32. MonthlyBill customer account while separately verifying bill details for 

33. . . . another customer. 

This satisfies the RI rule mentioned earlier, because Providing for these multiple LUWs demands mechanisms 

Customers have a lower weight (28) than Accounts (30). 45 which ensure integrity. Specifically, as with any LUW, a 

Thus, requests for customers will appear in any transaction primary LUW must isolate its own changes. It is an inde- 

before requests for accounts. As long as the order satisfies pendent workspace which prevents its changes from aflfect- 

every RI rule, the request sorter can use such a linear ing other LUW. 

ordering. However, an MVC-based OO architecture does not natu- 
This sort ordering can be created programmatically. A sort 50 rally support this requirement. With MVC, the domain 
generator can convert pairwise relation^ips into linearly- model stores all data changes. Endows are merely a view 
ordered weights. Then, the Request Sorter could use an into this model, and they have httle business data of their 
algorithm like Quicksort to do the actual sorting. own. In addition, MVC model objects have no idea which 
(Alternatively, object requests could be sorted as they are views are using them. Instead, the model anonymously 
registered, a la Insertion Sort.) 55 broadcasts its data changes, and all views on the model 
A centralized store-and-forward site must hold requests, respond by updating themselves. This synchronizes win- 
before they send themselves to the server. Otherwise they dows with their business data. Thus, MVC allows multiple 
cannot be sorted as a group. Request Batcher provides a views to simultaneously display, and be refreshed by, a 
centralized place to attach a sorter. single copy of the model data. 

Separate Models 60 FIG. 192 illustrates the MVC Implementation with Global 

FIG. 191 illustrates a flowchart for a method 19100 for Model, 

assigning independent copies of business data to concunent Unfortunately, this benefit of MVC introduces a problem, 

logical units of work for helping prevent the logical units of A globally-shared domain model does not naturally separate 

work from interfering with each other. In operation 19102, concurrent LUWs. It puts a burden on business "activity" 

multiple logical units of work operating concurrently are 65 objects, which coordinate the high-level business processing 

provided. Each of the logical units of work manipulate at across their domain models. Each activity has to either avoid 

least one common business object. In operation 19104, a overiap or know specifically how it affects the model. 
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Consider a telecommunications system, with two separate FIG. 194 illustrates the Canceling of one LUW 19400 

business LUWs for paying bills and adding new services. Independently of Another LUW 19402. 

like call waiting. An end user might launch windows for Thus, using Separate Models preserves the integrity of 

these two LUWs simultaneously. This would allow the user business LUWs. It allows each LUW to easily save or cancel 

to multi-task while conversing with the customer. 5 independently. 

Both windows display Account and Customer informa- . '""^ P^^^™ ^ intended to aUow different LUWs to 

tion. In addition, the Account Services window actually smiultaneously change their different physical ^^^^^ 

modifies the Account object, whereas the Account Payment logical entity. In fact, if both window^ modifi^ ttieir 

window does not. Making a payment only modifies the Bill ^^l^J^Vv ^^^Z* f 7""^^ * 

Paymentobject.Bothwi^o4,^ngMVC,couldsharethe lo ^^J^^lje c>ptunisUc lockmg would detect the da^ 

same Account 101 instance. ^^^^^ t4 ^ ^1 design doesn't typi- 

It is not atypical for custom architectures to have generic cally allow simultaneous but separate LUWs to update the 

mechanism for persistence and transactions. For example, same data. And this was not an issue in the example above, 

the architecture could use a straightforward mechanism Updates to the Account object occur on the Account Ser- 

which automatically saves all business objects within an vices window but not the Account Payment window. 

LUW. Then, when the user saves the Accoimt Payment Benefits 

window, the changes to Account 101 would be acddentally Isolation. Most fundamentally, this pattern solves the 

saved as well. The user would then not be able to later cancel Isolation requirement of ACID. It ensures that each 

changes on the Account Services window. This violates the LUW has its own 'Svorking storage" copies of business 

isolation of the two LUWs. 20 data. 

A similar problem might arise with a garbage collection Tran^arency. Separating models can be done in an archi- 

firamework, which exphdtly destroys all instances once the fashion, as outlined in the implementation sec- 

LUW has completed. In this case. Account Payment would ^® separation of LUWs—which is a technical 

need to ensure it did not explicitly free the memory for issue— can be hidden completely from business logic. 

Account, while Account Services was still using it ^ Imagine mstead that LUWs didn't have their own copies. 

™ - . ji ,j Then, each operation might need an additional arcu- 

Therefore, using a global, MVC model may preclude ttiw • j * i. in-- U 

♦t- u * * u • ^ J t_i mGul: the LUW ownmg the data change. This would 

usmg ote architecture mechanisms. To avoid the problems ^^^^ application code with an extra "^ansaction IIT 

of overlappmg saves or releasing memo^ argument, as in setBalance(newBalance, 

wmdows could have additional code to ensure the LUWs 3^ transaction^). As previously mentioned, this is only 

reniam separate. However, adding application-specific code ^^^^ of an Object Transaction Moni- 

m ^ mamier, to handle a global technical requirement, is tor. An OTM can transparenUy manage the transaction 

undesirable. ^^h the thread, without including it as an expHdt 

Instead, business LUWs should be able to modify domain argument, 

data independenUy of each other, tran^arenUy in the archi- 35 Uniformity, y^plication developers don't need to know 

tecture. In addition, each data change should unambiguously about which objects may or may not be used by other, 

belong to a single, originating LUW. concurrent LUWs. 

Modem Object Transaction Monitois promise to provide The following implementation assumes that the LUW 

this capabihty. These products will handle locking, tracking Context pattern is used to help separate the LUWs. 

which LUW has made changes to which piece of data, etc. 40 Each instance of a business object knows which LUW 

However, in the absence of an OTM, a custom ardiitecture owns it. That is, each instance knows its context. By 

needs a different approach. definition, context gives something a scope, a frame of 

Therefore, separate business LUWs by giving eadi LUW reference, a relationship to other things. To provide this 

separate copies of business data. relationship, an actual LUW Context object will hold onto 

Rather than using a globaUy-shared model, each business business objects which share a business LLTW. 

LUW will own a private, scratchpad copy of its domain ^° addition, each business object can point to its context, 

model. ITiis satisfies the independence requirement. Abusi- ^° manner, business (Ejects know their LUW. This 

ness object in one model will automatically be a separate ^^^'^ ^ usefiil, for example, while building a domain 

insUnce from a business object in another model, even if P*^^°^ ^^i^^ propagate its context to 

they share the same fimctional identity. For example, simul- ^° ^ child object. 

taneously opened payment and services windows would Busmess objects owned by the same business LUW share 
have separate copies of Account 101. ^® Context, whereas different LUWs have 
. j . ^* t • 1 Ml t L diffcrcnt contexts. Each context therefore contains its own 

Then, changes made to a particular mstance will only be ^ * *u -i i t^- 77^ 7 

„fl«-^ J * *u T Ti«7 u- u ^ J J working-storage copy of the model. This delineates an 

reflected m the LUW which created and pomts to that - j* i 3r * u j r ^^Tr^r 

instance. This contrasts with a single, globally-shared "ndrndual woAspace, or scratchpad^^ ^ 

model. Tie latter would simultaneoSi; reflect changes , ""KT ' ^'■^'y,'^««='jhich represents a 

across multiple LUWs. busmess LUW has its own context object. That context 

remams with the activity throughout its entire lifecycle. For 

FIG. 193 illustrates the Separate Models for Separate initiaHzation, creating a new LUW activity also creates a 

Busmess LUWs 19300,19302. go new context instance for that activity. This context will then 

The aforementioned telecommunications example had be passed downwards, to all business objects, as part of 

two separate business LUWs for the account payment and navigation. 

account services fiinctions. Although both activities may be Eventually, when the activity closes, it releases its LUW 

related by the same logical account, this pattern gives each Context. This correspondingly releases all business objects, 

a different context copy. Then, when the customer represen- 65 They can then be gaibage collected, because the only LUW 

Utive cancels the addition of call waiting, she can still save using those objects just closed. A context's lifecycle there- 

the payment details. fore corresponds directly to its activity's lifecycle. 



} 
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Preserving Context Boundaries 

Every context has a scope which limits the business LUW. 
This context boundary cannot be violated with objects from 
other LUW Contexts. For, the same instance of a business 
object cannot live in two different contexts. Otherwise, ^ 
changes made to that instance would affect two different 
LUWs. 

It is often necessary, however, to pass a business object as 
a parameter from one context to another. For example, a user 
may open up a customer details window based on a selection 
from a search window. The selected customer becomes the 
focus of the new window, but it was iiistantiated in the 
search context. It is the responsibility of the details window 
to take the passed-in customer and make a context copy of 
it. A context copy duplicates the original's data, excluding 
the context variable, which is re-set to the new context. The 
copied customer can then be safely xised and modified within 
the details context. 

A business object can be passed as parameter to another 
context as: ^ 
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// then use reflection to call the right public setter on the activity. 
newPiorateActivity,receive(aCorTecte(lMeterRead, 
"setCorrectedRead"); 

// Other initialisation here ... 
newProrateActivity.staitupQ; 



the single focus of a window that is being created 

a parameter in an explicit parameter-passing mechanism 

For example, when a business object is the focus of a new 

activity, the launching activity could instantiate the new 

activity as follows: 

MeterMaintenanceActivity::prorateMeterRead(MeterRead 
aMeterRead) 



25 



{ 

// Creates a new activity to prorate <aMeterRead>. This will manually 
adjust the 

// read chaiges, based on conecdons from the location, the office, etc. 
// Pseudo-code below. 

// Create the new activity instance by reflection, based on the class 
name, and 

// give it a new context and <aMeterRead> as focus. 
newProiateActivity - this.newActivity( 
thi8.proTateMeterReadClassNameQ, 
aMeterRead); 
// Other initialisation here „. 
newProrateActivity.startupO; 



The newActivity( ) architecture method instantiates a new 
activity, instantiates a new context, and creates a context 
copy of aMeterRead that the new activity can use. 

Sometimes an activity cannot get enough information 
simply by navigating from the focus. Non-focus information 
that must be passed as an additional parameter could be 
handled in the following manner: 
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MeterMaintenanceActivity::prorateMeterReadWithCorrection( 

^ MeterRead originalMeterRead, MeterRead correctcdMeterRead) 55 

// Creates a new activity to prorate <originalMeterRead> based on 
measurements 

// in <conectedMeterRead>. Pseudo-code below. (Duplicates some 
code above 
// for clarification.) 

// Create the new activity instance by reflection, based on the class ^ 
name, and 

// give it a new context and <origLiialMeterRead> as focus. 
newProrateActivity = this.newActivity( 

this.proniteMeterReadClassNameO» 

originalMeterRead); 
// Pass along the coirected read, as well. This will create a context ^5 
copy and 



Here, the receive( ) framework method allows any busi- 
ness object to be passed across the context boundary. The 
receiving activity will automatically create a context copy 
and then call the specified setter method, with the copy as 
argument. The setter is application-specific, and it allows the 
activity to handle and store the context copy wherever it 
wants. 

FIG. 195 illustrates the Context Copying Protects Context 
Boundaries. 

A dirty object should not be safely copied into a new 
LUW context. Otherwise, the second LUW would begin 
using infonnation that was half-completed in the fir^ LUW. 
Again, this violates the isolation requirement. The second 
LUW could save its changes before the first LUW. This 
means the first LUW couldn't undo any changes it had made 
to the dirty object. Instead, to avoid this problem, an 
exception should be thrown when trying to copy dirty 
objects across contexts. This disallows users from beginning 
a new LUW based on half-entered data. 

Thus, context copying allows LUW contexts to share 
parameter information while preserving context boundaries. 
Persistence Caching 

Although LUW contexts manipulate separate copies of 
business objects, they can often share the same retrieved 
data stream. For example, when a workstation retrieves data 
for Customer ABCD, the returned stream can be stored in a 
global cache. If another context wants to later instantiate its 
own copy of Customer ABCD, it can reuse the details stored 
in the stream cache. This improves performance, by avoid- 
ing a reduiKlant request to the remote data store. 
Context "Refresh" 

Each LUW, while working on its data, is independent of 
the other LUWs. From that perspective, each LUW context 
manipulates data that, to its knowledge, is the most current 
information from the data store. One instance's dianges 
remain invisible to another copy of the same business entity, 
during the course of normal processing. 

However, when an LUW context successfully commits 
changes, it will have more current data than other contexts 
which it intersects. This up-to-date data can be broadcast and 
shared with the other contexts. These contexts can then 
decide to transparently incorporate the changes or not. 

This refresh mechanism can be complex to build, and it 
requires an imderstanding of locking issues. For example, 
does the window have any changed data which might 
conflict with the new data? This would make the changes 
which hadn't yet been committed invalid, and the user 
would need to be notified. 

Althotigh only a few embodiments of the present inven- 
tion have been described in detail herein, it shoidd be 
understood that the present invention may be embodied in 
many other specific forms without departing from the spirit 
or scope of the invention. Therefore, the present examples 
and embodiments are to be considered as illustrative and not 
restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the 
appended claims. 



us 6,636^42 B2 



307 



308 



What is claimed is: 

1. A method for using a view configurer within a multi- 
layered architecture for managing the relationship between 
a plurality of activities and a plurality of views, with 
communication between layers being transmitted exclu- 
sively downward allowing the plurality of views to com- 
mxmicate directly with the plurality of activities but not 
allowing the plurality of activities to communicate directly 
with the plurality of views, comprising the steps of: 

(a) registering a server-based view configurer with a 
client-based activity factory to indicate an interest in 
initiated activities, wherein the initiated activities are 
made up of business logic, and wherein the phirahty of 
the initiated activities are executed on a client and are 
in cooununication with the serven 

(b) instructing a first activity to initiate a second activity, 
wherein the first activity and the second activity origi- 
nated firom the plurality of initiated activities, wherein 
the first activity is associated with a first view, and 
wherein the first activity receives instmctions to initiate 
the second activity from the first view; 

(c) initiating an instance of the second activity; 

(d) receiving a broadcast notification that an initiation 
event of the second activity has occurred, wherein the 
broadcast notification is transmitted by the second 
activity, and wherein the broadcast notification is 
received by the view configurer absent the second 
activity knowing of the existence of the view config- 
urer; 

(e) receiving a reference to the instance of the second 
activity, wherein the reference is received by the view 
configurer; 

(f) determining a second view to launch in response to the 
receipt of the broadcast notification and the reference, 
wherein the second view is based on predetermined 
criteria, wherein the predetermined criteria is user 
preferences, an experience level of a user, security 
profiles, and workflow settings, and wherein the second 
view is determined by the view configurei; 

(g) associating the second view with the second activity; 
and 

(h) di^laying the second view. 

2. A method as recited in claim 1, wherein the second 
activity is allowed to run without a corresponding view. 

3. A method as recited in claim 1, wherein the second 
activity operates on a machine separate from a machine of 
an end user. 

4. A method as recited in claim 1, further comprising the 
step of sending a request to be notified when a new instance 
of an object is created. 

5. A method as recited in claim 1, further comprising the 
step of reading from a configuration file for obtaining 
configuration information. 

6. A computer program embodied on a computer readable 
medium for using a view configurer within a multi-layered 
architecture for managing the relation^ip between a plu- 
rality of activities and a plurality of views, with communi- 
cation between layers being transmitted exclusively down- 
ward allowing the plurality of views to communicate 
directly with the plurality of activities but not allowing the 
plurality of activities to communicate directly with the 
plurality of views, comprising: 

(a) a code segment that registers a server-based view 
configurer with a client-based activity factory to indi- 
cate an interest in initiated activities, wherein the 
initiated activities are made up of business logic, and 
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wherein the plurality of the initiated activities are 
executed on a chent and are in communication with the 
server, 

(b) a code segment that instructs a fiist activity to initiate 
a second activity, wherein the first activity and the 
second activity originated from the plurality of initated 
activites, wherein the first activity is associated with a 
first view, and wherein the first activity receives 
instructions to initiate the second activity from the fiist 
view; 

(c) a code segment that initiates an instance of the second 
activity; 

(d) a code segment that receives a broadcast notification 
that an initiation event of the second activity has 
occurred, wherein the broadcast notification is trans- 
mitted by the second activity, and wherein the broad- 
cast notification is received by the view configurer 
absent the second activity knowing of the existence of 
the view configurer; 

(e) a code segment that receives a reference to the instance 
of the second activity, wherein the reference is received 
by the view configurer; 

(f) a code segment that detemaines a second view to 
laimch in response to the receipt of the broadcast 
notification and the reference, wherein the second view 
is based on predetermined criteria, wherein the prede- 
termined criteria is user preferences, an experience 
level of a user, security profiles, and workflow settings, 
and wherein the second view is determined by the view 
configurer; 

(g) a code segment that associates the second view with 
the second activity; and 

(h) a code segment that displays the second view. 

7. A computer program as recited in claim 6, wherein the 
second activity is allowed to run without a corre^nding 
view. 

8. A computer program as recited in claim 6, wherein the 
second activity operates on a machine separate from a 
machine of an end user. 

9. A computer program as recited in claim 6, further 
comprising a code segment that sends a request to be notified 
when a new instance of an object is created. 

10. A computer program as recited in claim 6, further 
comprising a code segment that reads from a configuration 
file for obtaining configuration information. 

11. A system for using a view configurer within a multi- 
layered architecture for managing the relationship between 
a plurality of activities and a plurality of views, with 
communication between layers being transmitted exclu- 
sively downward allowing the plurality of views to com- 
municate directly with the plurality of activities but not 
allowing the plurality of activities to conmaunicate direcfly 
with the plurality of views, comprising: 

(a) logic that registers a server-based view configurer with 
a client-based activity factory to indicate an interest in 
initiated activities, wherein the initiated activities are 
made up of business logic, and wherein the plurality of 
the initiated activities are executed on a client and are 
in commimication with the server; 

(b) logic that instructs a first activity to initiate a second 
activity, wherein the first activity and the second activ- 
ity originated from the plurality of initiated activities, 
wherein the first activity is associated with a first view, 
and wherein the first activity receives instructions to 
initiate the second activity from the first view; 

(c) logic that initiates an instaiice of the second activity; 
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(d) logic thai receives a broadcast ootLfication that an 
initiation event of the second activity has occurred, 
wherein the broadcast notification is transmitted by the 
second activity, and wherein the broadcast notification 
is received by the view configurer absent the second 
activity knowing of the existence of the view config- 
urer, 

(e) logic that receives a reference to the instance of the 
second activity, wherein the reference is received by the 
view configurer; 

(f) logic that determines a second view to launch in 
response to the receipt of the broadcast notification and 
the reference, wherein the second view is based on 
predetermined criteria, wherein the predetermined cri- 
teria is user preferences, an experience level of a user, 
security profiles, and workflow settings, and wherein 
the second view is determined by the view configurer; 

(g) logic thai associates the second view with the second 
activity; and 

(h) logic that displays the second view. 
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12. A system as recited in claim U, wherein the second 
activity is allowed to mn without a corresponding view. 

13. A system as recited in claim U, wherein the second 
activity operates on a machine separate from a machine of 
an end user. 

14. A system as recited in claim 11, further comprising 
logic that sends a request to be notified when a new instance 
of an object is created. 

15. A S3^em as recited in claim 11, further comprising 
logic that reads from a configuration file for obtaining 
configuration information. 

16. A method as recited in claim 1, wherein the activity 
factory broadcasts the notification of the startup event of the 
activity. 

17. A method as recited in claim 1, wherein a new instance 
of each of the plurality of activities is created by the activity 
factory. 



